 |
 |
On Dec 1, 2013, at 11:12 PM, Simon Spero wrote: > On Dec 1, 2013 6:42 PM, "Joe Hourcle" <[log in to unmask]> wrote: > >> So that you don't screw up web proxies, you have to specify the 'Vary' > header to tell which parameters you consider significant so that it knows > what is or isn't cacheable. > > I believe that if a Vary isn't specified, and the content is not marked as > non cachable, a cache must assume Vary:*, but I might be misremembering That would be horrible for caching proxies to assume that nothing's cacheable unless it said it was. (as typically only the really big websites or those that have seen some obvious problems bother with setting cache control headers.) I haven't done any exhaustive tests in many years, but I was noticing that proxies were starting to cache GET requests with query strings, which bothered me -- it used to be that anything that was an obvious CGI wasn't cached. (I guess that enough sites use it, it has to make the assumption that the sites aren't stateful, and that the parameters in the URL are enough information for hashing) >> (who has been managing web servers since HTTP/0.9, and gets annoyed when > I have to explain to our security folks each year why I don't reject > pre-HTTP/1.1 requests or follow the rest of the CIS benchmark > recommendations that cause our web services to fail horribly) > > Old school represent (0.9 could out perform 1.0 if the request headers were > more than 1 MTU or the first line was sent in a separate packet with nagle > enabled). [Accept was a major cause of header bloat]. Don't even get me started on header bloat ... My main complaint about HTTP/1.1 is that it requires clients to support chunked encoding, and I've got to support a client that's got a buggy implementation. (and then my CGIs that serve 2GB tarballs start failing, and it's calling a program that's not smart enough to look for SIG_PIPE, so I end up with a dozen of 'em going all stupid and sucking down CPU on one of my servers) Most people don't have to support a community written HTTP client, though. (and the one alternative HTTP client in IDL doesn't let me interactive w/ the HTTP headers directly, so I can't put a wrapper around it to extract the tarball's filename from the Content-Disposition header) -Joe ps. yep, still having writer's block on posters.