NYCPHP Meetup

NYPHP.org

[nycphp-talk] NEW PHundamentals Question - Headers & Downloads

Hans Zaunere hans at nyphp.com
Sun Oct 24 19:02:35 EDT 2004


> > I've run into some tricky problems with IE and SSL. Now some
> > would argue that this is a bug, but I think IE is actually
> > inline with the standard. Details are at:
> >
> > http://support.microsoft.com/default.aspx?scid=KB;EN-US;q316431&
> 
> Interesting. I agree with those who would argue that this is a bug.
:-)
> 
> Section 14.9.1 of RFC 2616 is where you want to read to determine
whether
> you agree with my intrepretation. Of particular note is the opening
> description of no-cache:
> 
>     If the no-cache directive does not specify a field-name, then
>     a cache MUST NOT use the response to satisfy a subsequent
>     request without successful revalidation with the origin server.
> 
> >From the description on Microsoft's Web site, it sounds like you
simply
> cannot display a Word document in the browser when the no-cache
directive
> is set, which makes no sense at all. If this is true of Word
documents,
> why is it not true for HTML? The HTTP specification does not advocate
> inconsistent interpretation of the specification depending upon the
> content type. I don't even see how anyone could pose a good argument
in
> favor of this.

Could be a bug, but RFCs are often buggy themselves  :)

The argument, I suppose, of IE's behavior is related to the "Cause"
subheading in the Microsoft article, above.  An HTML file is only loaded
into memory, while an Office or some other "out-of-process, ActiveX
document server" type of file needs to be stored on disk temporarily.
So, it's not a difference in the MIME type at the HTTP level, but in the
way the OS needs to deal with the file.  Actually, the behavior is
exactly the same for Mozilla, et al (they need to write the downloaded
file to a temporary file), though they don't have this behavior, even
with SSL.

Six, half dozen the other...

> It seems to me that someone at Microsoft has confused no-cache with
> no-store. The irony is that the opposite worked in favor for Microsoft
> during the browser wars. When a resource used no-store, Netscape would
> request the resource again for simple things like printing, whereas
> Internet Explorer would not. Anyone remember this?
> 
> I've cited sections of RFC 2616 before that might explain this
> inconsistency regarding the interpretation of no-store, but I cannot
think
> of a defense for Microsoft's interpretation of no-cache, unless it's
based
> purely on semantics and not on the specification.

You may be exactly right, in that they are confused with the difference
between no-cache and no-store.  Then again, I think sometimes the RFC
confuses them.

> > Another gotcha, that I can't resolve, actually involves Mozilla.
> > For instance, Mozilla (and derivatives) always append the file
> > extension of the type of page originally viewed.
> 
> I would argue that this is a bug in Mozilla. :-) I've heard of this
also,
> and I'll try to recall the workarounds. Mozilla is not alone on this,
as
> Internet Explorer has been known to have similar problems, and it even
> goes a step further by not just ignoring the filename given in
> Content-Disposition, but also the content type given in Content-Type.
> 
> > For instance, in phpMyAdmin, downloading a .sql file will be
> > saved as a .sql.php file. I frankly haven't looked too deeply,
> > but a work around for the future would be nice.
> 
> Would you mind taking a look to see if phpMyAdmin sends the correct
> Content-Disposition header? I wouldn't assume that the browser is
> necessarily the one at fault here. :-)

With Firefox 1PR1 this actually has gone away, even with old versions of
phpMyAdmin.  Unfortunately, livehttpheaders doesn't seen to be available
for this release yet.

> > So at the end of the day, I think it's somewhat of a black art.
> 
> I totally agree, which is what makes this a great Phundamental.
> 
> > Getting some definitive answers from the Browser/HTTP/Front-End
> > guys would be invaluable.
> 
> Everyone can help with this by doing some testing, especially if
you've
> encountered any of the problems Hans and I have referenced. It's been
> quite a while since I researched this, so I'll have to dig up some
notes
> to hopefully find some better answers.

Ditto - people sharing their experiences and the environment they occur
in is vital.  Thus, hopefully, creating a matrix of sorts with all the
permutations.

H




More information about the talk mailing list