Subject: [apps-discuss] Fwd: I-D Action: draft-nottingham-http-browser-hints-00.txt

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

FYI.

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: Mark Nottingham <[email-masked]>
Date: Tue, 17 May 2011 16:16:48 +1000

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

Cheers,

---

From: Dzonatas Sol <[email-masked]>
Date: Tue, 17 May 2011 07:07:16 -0700

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

The ReSTful paradigm is useful here such that any specific field in the 
browser-hints file can be found by path.

GET /.well-known/browser-hints/max-conns

I'm sure this leads to PUT, POST, and DELETE methods as well for easier 
connection negotiation, management, and hints of what paths are 
streams/pipelines, or like capabilities.

For example, I use these next two to combine all data into one stream 
that appears like a structure, with the specific path:

GET /.well-known/browser-hint/s   # all hints with data in XML format
GET /.well-known/browser-hint      # list of categories known in XML format

As above:
GET /.well-known/browser-hints    # suggested default for JSON fromat

I suggest this "symbolic" reservation for *explicit* stream methods and 
logical devices  (combined path use-cases from SYSV, VMS, and 
IETF-VWRAP-LLIDL)
GET /.well-known/browser-hint$
GET /.well-known/browser-hint$max-conns

Conservative approach to avoid query arguments or extra headers that 
specify format:
GET /.well-known/browser-hint.xml         # XML alternative
GET /.well-known/browser-hint.json         # JSON alternative
GET /.well-known/browser-hint.json.xml  # json in XML format: 
https://datatracker.ietf.org/doc/draft-rsalz-jsonx

I think XSLT with optional script can be used for further 
transformations of paths and streams.

-- 
--- https://twitter.com/Dzonatas_Sol ---
Web Development, Software Engineering, Virtual Reality, Consultant

---

From: Dzonatas Sol <[email-masked]>
Date: Tue, 17 May 2011 08:54:31 -0700

For those interested in interoperability of where I suggested ReSTful 
paradigm, here is one use-case:

Portable web-server in client web-browser, see here for basis without 
network installed:  http://bellard.org/jslinux 
<http://bellard.org/jslinux/tech.html>
Technicals: http://bellard.org/jslinux/tech.html

Imagine several dozens of those in one web page; then, the gist of how 
all instances can update or save themselves through provider means is 
little more obvious. I thought the above is useful reference to further 
design intermediary states and stateful/stateless implementation, 
especially where each instance/region is thought in terms of IPv4 and 
the outer frame is IPv6.

The complete idea of this use-case includes capabilities that enable 
intermediate systems rather be stuck in monolithic support requirements: 
"How do we save all these great ideas and not need to implement one 
single way?"

On 05/17/2011 07:07 AM, Dzonatas Sol wrote:
>> I have a pretty strong suspicion that this will end up being too 
>> complex, but let's see what others think.
>>
>
> The ReSTful paradigm is useful here such that any specific field in 
> the browser-hints file can be found by path.
>
> I'm sure this leads to PUT, POST, and DELETE methods as well for 
> easier connection negotiation, management, and hints of what paths are 
> I suggest this "symbolic" reservation for *explicit* stream methods 
> and logical devices  (combined path use-cases from SYSV, VMS, and 
> IETF-VWRAP-LLIDL)

--

---

From: Brian Pane <[email-masked]>
Date: Wed, 18 May 2011 19:03:46 -0700

Reading through the browser hints draft,
http://www.ietf.org/id/draft-nottingham-http-browser-hints-00.txt , my
first reaction is that it specifies a really arbitrary subset of
request headers that clients can be advised to stop sending.

While there's definitely some benefit to be gained by addressing
special cases like this, I think a general-case solution would be
preferable: a hop-by-hop response header that tells the client that
the server (or intermediary) supports compressed headers.  This would
require the definition of a compressed header standard, of course.

Of the specific headers covered in the draft, many have the same
values on every request: Accept, Accept-Charset, User-Agent.  Header
compression would be very effective for these and for some other
common headers: Host, X-Forwarded-For, and Accept-Encoding.  In
addition, Cookie and Referrer would benefit from compression in a lot
of common cases.

-Brian

---

From: Dzonatas Sol <[email-masked]>
Date: Wed, 18 May 2011 22:45:43 -0700

#!twitter.com/Dzonatas_Sol/status/71018131946082304

Proven standard and extensible with channel persist objects; it works in 
less than #140.

On 05/18/2011 07:03 PM, Brian Pane wrote:
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss
>
>    

--

---

From: Dzonatas Sol <[email-masked]>
Date: Thu, 19 May 2011 10:41:40 -0700

For those that are new to such concept, or can't make heads or tails out 
of "the content", I explained the basics of the code here:

http://icyspherical.blogspot.com/2011/05/unix-in-xml.html

And, why we do not put the spin on hypermedia: 
http://lists.w3.org/Archives/Public/ietf-http-wg/2011AprJun/0240.html

We did our homework (for Science of the Letters).

On 05/18/2011 10:45 PM, Dzonatas Sol wrote:
> Proven standard and extensible with channel persist objects; it works 
> in less than #140.
>

--

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 20 May 2011 10:51:30 +1000

Hi Brian,

I've been thinking about HTTP compression schemes too, but IMO the barrier to entry for hop-by-hop is probably too high, as that's getting perilously close to HTTP 2.0, and if we're going to go that far, we might as well go the whole hog (a la SPDY, WAKA, etc.). Also, header compression only works well if you have many requests on a connection; IME we're not there yet.

Rather, I'm seeing this draft as a mechanism for backing away from the spiral of unfortunate behaviours that the browsers have to implement to interoperate with really broken sites. My site doesn't need convoluted Accept-* headers, nor does it need a painfully wordy User-Agent, but the browsers still send the because some other broken sites do require this. Likewise, my site doesn't need browsers to be careful about pipelining.

Also, there is more in the draft than just reducing request header sizes; while that might be the most beneficial case for you, I actually started the draft for the pconn-ip behaviour. 

Regards,

---

From: Brian Pane <[email-masked]>
Date: Fri, 20 May 2011 02:52:12 -0700

On Thu, May 19, 2011 at 5:51 PM, Mark Nottingham <[email-masked]> wrote:

> Also, header compression only works well if you have many requests
> on a connection; IME we're not there yet.

My experience has been that the number of requests per site (scheme+authority)
often is large enough to make header compression interesting, but that number
divided by ~6 (a modern browser's connection parallelism) usually isn't.  Thus I
see header compression being viable in combination with another change: hinting
to the client that it should use pipelining and a smaller number of connections.
But yes, at that point we're halfway to reinventing SPDY.

> Also, there is more in the draft than just reducing request header sizes; while
> that might be the most beneficial case for you, I actually started the draft for
> the pconn-ip behaviour.

The pconn-ip hint looks good.  The only complication I can think of is that the
client implementer will have to decide whether to manage the maximum size
of its persistent connection pool on a per-IP-addr or per-site basis.  E.g., if
static.example.com and images.example.com resolve to the same address,
a typical browser today might open N concurrent connections to static and
another N connections to images.  If the client honors the pconn-ip hint for
both those sites, it needs to decide on a suitable number of concurrent
connections.  Some possibilities that come to mind are:
  N (may reduce concurrency)
  Some fixed number P > N
  M*N, where M is the number of sites that resolve to the same addr
        (that the client knows about)
None of those is really ideal, though.

Finally, some notes on max-conns: I think it's a good hint, as it leads server
side applications away from having to use tricks like domain sharding.  And
for servers that can handle a lot of concurrent connections, the ability to tell
the client that it's okay to open some very large number of persistent
connections
reduces the need to come up with a pipeline hinting standard.  The catch, I
think, is that the clients most in need of a hint to increase their connection
limit are specific old browser versions, still in widespread use, that
aren't likely
to ever be updated with support for a new browser hint standard.

-Brian