When I try to save a generated XML document (would check with standard xml doc) the saved file contains garbage (binary data). Verified with 0.9.3 && Netscape 6 (0.8) (Both windows/linux)

does winzip recognize it if you rename it to something.gz?

Yes. This is a Gzipped format. Changing bug summary.

Do you have a URL for such an XML doc?

There were a couple of bugs on this fixed after 0.9.3 was released. Can you try with a later build, or wait for 0.9.4?

I can't D/L a new version. My current test url : http://prixmateriel.com/xmltemp (will be avail. for 2 days) This seems to happen only with remote generated pages. When I do the same on my own http server, the saved result is correct. So, this may be related to headers returned by the web server that corrupts encoding when saved. (Just suppositions)

I see this with current Linux cvs Try opening this URL in Mozilla: http://prixmateriel.com/xmltemp?categorie%5B0%5D=145&action=Selectionner That comes up fine. Then save the file (ctrl-s). It's saved as gzip. Is this a content-negotiation problem? Will this go away once save as no longer rehits the server? Headers from a normal load of that url (via wget or telnet): HTTP/1.1 200 OK Date: Thu, 13 Sep 2001 16:36:48 GMT Server: Apache Content-Location: xmltemp.php3 TCN: choice Vary: negotiate X-Powered-By: PHP/4.0.4pl1 Transfer-Encoding: chunked Content-Type: text/html

For info: I got the same error/behaviour with Opera 5 but not MSIE.

hmm. my comment got lost. Anyway, quick summary: a) bz - can you repeat that using TestProtocols - the client needs to send an Accept-Encoding header for the server to send gziped content back. b) The problem is that Content-Encoding shouldn't be applied for save-link-as, and there were arguments that save-as shouldn't be different to save-link-as. There were arguments that having save-as not save what you see was confusing. I can't remember what we decided, and can't find a bug on it. -> darin, who has that table on the whiteboard of his cube

->B.Baetz: By default, Mozilla sends and accept gzipped and zipped format string into http request headers. But the script here is not configured to reply in gzipped content. -> This is the reply of my own server which produce correct ,when saved, document. HTTP/1.1 200 OK Date: Thu, 13 Sep 2001 17:25:15 GMT Server: Apache/1.3.14 (Unix) PHP/4.0.6 Content-Location: xml.php3 Vary: negotiate TCN: choice X-Powered-By: PHP/4.0.6 Connection: close Content-Type: text/html

bbaetz- > can you repeat that using TestProtocols Could you email me directions on what that means?

bz: TestProtocols is a binary in dist/bin, which just downloads a URL. just specify the URL on the command line and watch what gets written to your terminal.

bz: see darin's comment. I won't have net access at home til next week, so I can't test.

Darin, thanks. Here's the output: HTTP request headers: Host: prixmateriel.com User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4+) Gecko/20010812 Accept: text/xml, application/xml, application/xhtml+xml, text/html;q=0.9, image/png, image/jpeg, image/gif;q=0.2, text/plain;q=0.8, text/css, */*;q=0.1 Accept-Language: en-us Accept-Encoding: gzip, deflate, compress;q=0.9 Accept-Charset: ISO-8859-1, utf-8;q=0.66, *;q=0.66 Keep-Alive: 300 Connection: keep-alive sample-header: Sample-Value HTTP response headers: Date: Thu, 13 Sep 2001 20:14:12 GMT Server: Apache Content-Location: xmltemp.php3 TCN: choice Vary: negotiate, User-Agent X-Powered-By: PHP/4.0.4pl1 Keep-Alive: timeout=15, max=100 Connection: Keep-Alive Content-Type: text/html Content-Encoding: gzip Content-Length: 1500 Looks like we just save the raw data the server sent us, which is gzipped.

bz: thanks.. i have a patch in mind which might fix this.

bbaetz: some debates on content-encoding are in bug 51852, maybe that is the bug you were thinking of.

is this the same problem as in bug 86235, bug 86290, bug 94596, bug 99951

is this the same problem as in bug 86235, bug 86290, bug 94596, bug 99951 It really looks like, except we produce xml instead of HTML. Anyway, the server content-encoding is designed as the faulty one and it is surely the same problem. You can mark as dupe.

seems those all landed in bug 51852.

-> 0.9.6 (unfortunately)

-> probably won't get a chance to look at this until 0.9.9 or so :(

bz: your testcase seems to work now.... WFM?

WORKSFORME linux build 2002010908

Yeah. We no gunzip _everything_ when saving, even things that should not be gunzipped. This is covered by other bugs, though.