Maya wrote: > My understanding was that Firefox sets the content-type header on the > channel based on the extension of the requested file/page.
There is no content-type header on the _request_ for a GET request. For the response, the contentType property of the channel is only set based on the URL if the server doesn't send a Content-Type header. In general, it's the responsibility of the protocol handler to set this property... It sounds like your problem is in the code that bug 300438 touched. In brief, the PDF plug-in makes byte-range requests if it thinks it can. Right now it thinks it can if: 1) The channel is an HTTP channel. 2) There is no Content-Encoding response header on the channel. 3) The contentLength property of the channel is not -1. 4) There is an Accept-Ranges response header on the channel. Chances are, these are true in your case... You may want to simply set the contentLength to -1 if you don't know what the length is... or set a Content-Encoding indicating that the data that came from the server is not the real data that the channel is sending out. -Boris _______________________________________________ dev-tech-xpcom mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-xpcom
