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

[ sending replies to apps-discuss ]

Hi Willy, 

On 17/05/2011, at 3:34 PM, Willy Tarreau wrote:

> Hi Mark,
> On Tue, May 17, 2011 at 02:23:29PM +1000, Mark Nottingham wrote:
>> A URL for this Internet-Draft is:
> 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.

Thanks, but they're orthogonal.

> I think that default values should be indicated for all values there.

The defaults are the current behaviours of implementations; anything else would make this mechanism non-optional, and introduce lots of problems.

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

Pipelining already has to be supported, if it's a HTTP/1.1 server. As has been discussed ad nauseum, a "I support pipelining" or even a "I really support pipelining" flag doesn't do anyone any good.

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

It'll work just like it does when you don't send the Accept-Headers values in HTTP today. Anything else would be introducing incompatible changes to HTTP.

> 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 suspect that the referer-related mechanisms are going to be refined, based on feedback I've already received. Also, see Adam Barth's related work on Origin. 

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

IME more complex deployments like this tend to develop back-end practices and tools to manage those issues.

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

I have a pretty strong suspicion that this will end up being too complex, but let's see what others think.

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

Possibly, but I'm not sure what that achieves, vs. the Keep-Alive header that's already implemented. Some servers also want this to be dynamic. See also Martin Thompson et al's work on timeouts.


Mark Nottingham

Received on Tuesday, 17 May 2011 06:17:20 UTC