Re: Fwd: I-D Action: draft-nottingham-http-browser-hints-00.txt

[Willy Tarreau <[e-mail]>]

Hi Mark,

On Tue, May 17, 2011 at 02:23:29PM +1000, Mark Nottingham wrote:
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-nottingham-http-browser-hints-00.txt

While I have still not replied to your previous mail about the pipelining
draft, I must say that I like this new proposal a lot more than the old one.

I think that default values should be indicated for all values there. For
instance, if a site complies with this draft and delivers a browser-hints
file, it means that it's likely to comply with many of the server
requirements, so pipelining should be supported for instance. Thus, we
could reasonably suggest that max-pipeline-depth is non-zero when not
specified.

For "small-hdrs", we should explicitly indicate what Accept* header values
will be used by the server when they are not sent by the browser.

Concerning the no-referer, we're risking that people always ask for a
referer header to be sent because they want to see how they're indexed.
My suggestion would be that we provide the ability not to send a referer
header for requests coming from the same site (eg: fetching images from
a site's page enlarges all requests for nothing). That could probably be
combined with the new Ref header you're proposing with various options :

   - no referer from the same site
   - relative referer only without query string
   - relative referer only with query string
   - full referer

I'm seeing a minor issue though : we're mixing there two distinct pieces of
information. We have infrastructure-related information (pipelining, concurrent
persistent connections, etc...) and application informationn (referer, ...).

Some large hosting infrastructures I know will like the connection related
informations to be directly delivered from outer shared reverse proxies for all
hosted sites, while the application-specific information will be delivered from
hosted applications. Eg: one app will want the referer while another won't care,
however neither knows what to announce for pipelining or persistent conns.

Thus we should probably have two distinct well known files. In order to
reduce the number of requests, we could suggest that if the browser-hints
file does not contain any connection information, then the browser is
invited to get /.well-known/connection-hints too as a complement.

Anyway I don't think that fetching two files is an issue, considering that
the connection-specific one would be cached much longer.

While we're at it, the same file could be used to announce the configured
keep-alive timeout so that browsers don't try to send requests over
supposedly dead connections.

Regards,
Willy