NYCPHP Meetup

[Chris Shiflett]

--- Hans Zaunere <hans at nyphp.com> wrote:
> 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.

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.

> 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. :-)

> 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.

Chris

=====
Chris Shiflett - http://shiflett.org/

PHP Security - O'Reilly     HTTP Developer's Handbook - Sams
Coming December 2004        http://httphandbook.org/