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

From: Mark Nottingham <[email-masked]>
Date: Tue, 17 May 2011 14:23:29 +1000

FYI. I've nominated the apps-discuss list as the place to discuss.

Begin forwarded message:

> From: [email-masked]
> Date: 17 May 2011 2:21:49 PM AEST
> To: [email-masked]
> Subject: I-D Action: draft-nottingham-http-browser-hints-00.txt
> Reply-To: [email-masked]
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> 
> 	Title           : HTTP Browser Hints
> 	Author(s)       : Mark Nottingham
> 	Filename        : draft-nottingham-http-browser-hints-00.txt
> 	Pages           : 8
> 	Date            : 2011-05-16
> 
>   Over time, Web browsers have adapted how they use HTTP based upon
>   common server configurations and behaviours.  While this is necessary
>   in the common case, it can be detrimental for performance and
>   interoperability.
> 
>   This document establishes a mechanism whereby origin servers can make
>   available hints for browsers about their preferences and
>   capabilities, without imposing overhead on their interactions or
>   requiring support for them.
> 
>   This is intended to allow browsers to safely optimise connections to
>   servers.
> 
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-nottingham-http-browser-hints-00.txt
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> This Internet-Draft can be retrieved at:
> ftp://ftp.ietf.org/internet-drafts/draft-nottingham-http-browser-hints-00.txt
> _______________________________________________
> I-D-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

--
Mark Nottingham   http://www.mnot.net/

---

From: Willy Tarreau <[email-masked]>
Date: Tue, 17 May 2011 07:34:16 +0200

Hi Mark,

> 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

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 17 May 2011 16:16:48 +1000

[ sending replies to apps-discuss ]

Hi Willy, 

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

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.

>   - relative referer only with query string

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. 

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

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

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

Cheers,