On Thu, Sep 07, 2000 at 02:55:32PM -0400, Tim Hunter wrote:
> I have been following this discussion with great curiosity since I hate this
> "feature" of IE.
>
> I found the following link on Microsoft's site that looks like it is similar
> to the problem faced
> HOWTO: Raise a "File Download" Dialog Box for a Known MIME Type
> http://support.microsoft.com/support/kb/articles/Q260/5/19.ASP
>
>
> -----Original Message-----
> From: Jason Baker [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, September 07, 2000 2:41 PM
> To: [EMAIL PROTECTED]
> Subject: Re: Possibly stupid problem with attachment types
>
>
> Dan Melomedman wrote:
> >
> > That information can be found on MS's site. I don't have a link handy
> > right now, but search for IE, and MIME types. There's an article that
> > desribes the algorithm it uses. In few words, they rely on other methods
> > to determine file types rather than just MIME types (looking at the
> > contents, and the actual URL).
>
> I'll take a peek at that... I halfway suspected that already, except I
> have
> seen it fire up Media Player to play the wave file, and then media
> player
> complains it can't find the file (IE: it wasn't actually saved to disk).
>
> > One trick you can do is modify Sqwebmail
> > so it writes a temporary file somewhere in the document tree, then
> > redirects the client to that file, then remove the file (since
> > IE seems to be able to download any files this way). You could also
> > force a known-to-work MIME type on all files, but that's just nasty.
> > Of course, a better solution would be for MS to release a
> > standards-compliant product. Amusingly enough,
> > ASP applications have no problems uploading generated files.
>
> Ah, but that's why it's not just a job, it's an ADVENTURE! Or at least,
> that's what I tell myself every time this kind of thing comes up. ;)
>
> I did some further poking with ngrep, though, and here's what I found in
> the returned headers. I've cleaned up the trace so it's all nice and
> linefed as well.
>
> Not through the proxy:
> HTTP/1.1 200 OK
> Date: Thu, 07 Sep 2000 18:23:26 GMT
> Server: Apache/1.3.12 (Unix) mod_ssl/2.6.4 OpenSSL/0.9.5a
> Cache-Control: no-store
> Content-Disposition: attachment; filename="WSWOOHOO.WAV"
> Pragma: no-cache
> Keep-Alive: timeout=15, max=100
> Connection: Keep-Alive
> Transfer-Encoding: chunked
> Content-Type: application/octet-stream; charset="us-ascii";
> name="WSWOOHOO.WAV"
>
> Through the proxy:
> HTTP/1.0 200 OK
> Date: Thu, 07 Sep 2000 18:21:32 GMT
> Server: Apache/1.3.12 (Unix) mod_ssl/2.6.4 OpenSSL/0.9.5a
> Cache-Control: no-store
> Content-Disposition: attachment; filename="WSWOOHOO.WAV"
> Pragma: no-cache
> Content-Type: application/octet-stream; charset="us-ascii";
> name="WSWOOHOO.WAV"
> Age: 0
> X-Cache: MISS from granite.canadamortgage.com
> Proxy-Connection: close
>
> A diff of the two:
> 513>diff headers_noproxy headers_proxy
> 1,2c1,2
> < HTTP/1.1 200 OK
> < Date: Thu, 07 Sep 2000 18:23:26 GMT
> ---
> > HTTP/1.0 200 OK
> > Date: Thu, 07 Sep 2000 18:21:32 GMT
> 7,9d6
> < Keep-Alive: timeout=15, max=100
> < Connection: Keep-Alive
> < Transfer-Encoding: chunked
> 10a8,10
> > Age: 0
> > X-Cache: MISS from granite.canadamortgage.com
> > Proxy-Connection: close
>
> The thing that jumps out at me is "Transfer-Encoding: chunked". I'll
> poke around the IE site to see if it has any known problems with that.
We have actually done similar analysis, and really tried all kinds of
MIME headers combinations (for our PHP scripts), gave up and just write
temporary files now :(.
What might make it work with the proxy is the URL.
How does the URL look in the proxy case? In the non-proxy case?
Also, does URL point to the actual file in the proxy case?
