- From: Amos Jeffries <squid3@treenet.co.nz>
- Date: Mon, 16 Jul 2012 13:43:43 +1200
- To: James M Snell <jasnell@gmail.com>
- Cc: <ietf-http-wg@w3.org>
On 16.07.2012 12:52, James M Snell wrote: > On Sun, Jul 15, 2012 at 1:58 AM, Amos Jeffries wrote: > >> On 15/07/2012 7:07 p.m., Poul-Henning Kamp wrote: >> >>> Amos Jeffries writes: >>> >>> Hopefully the result will be a BIG change towards simplicity. But >>> only >>>> time will tell about that. >>>> >>> I don't see any signs of that anywhere, care to elaborate what you >>> base your hope on ? >>> >>> >> "Hope is hope. If we had reasons, it'd be called surety" - >> Anonymous. >> >> We have the opportunity for reducing the HTTPbis specs into one spec >> which >> describeds the framing for HTTP/2 and flor controls. Leaving the >> rest of >> the protocol features out as separate optional extensions. There is >> hope, >> slim maybe, but hope. >> >> > While "leaving the rest ... out as separate optional extensions" > sounds > great if you're in the business of providing the fundamental > architecture, > it's not so great if you're building applications on top that rely on > those > "optional" pieces. Simplification is a great thing, but HTTP/2 can't > be > ONLY about the framing... it must also address very real issues that > exist > elsewhere in the specification. This sounds like you are arguing that we need to force mandatory Range: request support, mandatory caching, mandatory authentication, etc, etc. all the way down the stack from the web application which needs it, to the simple load balancers or "HTTP router" pushing HTTP/2 around a CDN hierarchy. I agree that application level implementations have a whole bunch of things they need to support. Browsers being probably the best example here, with have a far wider range of RFCs to support today than even just HTTP/1.1. CGI interface libraries not being far behind. I'm questioning why implementers have to be faced with reading and verifying compliance of all this detail as "The HTTP/2.0 Document" when the request details are controlled by an application and the reply is generated by one. Consider an HTTP server which runs a simple CGI library. The server can decode and multiplex the framing, but has no need to handle or even implement most of the finer details for features the CGI library can cope with. It just needs to pass on the request and assemble the response bits (CGI could encoded its specific application-level headers easily enough). -> the server needs compliance with HTTP/2 -> the CGI needs compliance with some application feature spec(s) it want to implement and HTTP/2 To take this to the extreme case; Should we also borg the entirety of WebDAV (an application feature definition) into the HTTP/2.0 document just because web application layer needs it? I think not. Neither do I think www-auth should be part of the core HTTP/2 specification. As opposed to proxy-auth in its role as connection authentication which *is* relevant to the transport level for even simple load balancers to handle properly. The SPDY draft is a good example of creeping the scope out beyond transport and the disagreements have *all* been focused around different "groups" needs being unmet by that all-in-one spec. If you read PHKs' arguments about spec page length with a grain of salt, these same points are what he is arguing about. A lot of the features we will be wanting to keep from HTTP/1.x (www-auth, ranges, caching etc being good ones). Describing their semantics in a separate document pointed at by both HTTP/2 and HTTP/1 would be a great way to simplify the texts and ensure semantic compatibility. New features may well be needing to define HTTP/1 backward compatibility and this style of specification would make it easier to extend 1.1+ Come to think of it, in our network-friendly draft we only specify version as far as "HTTP/2", the .x part is left unstated in the frame headers and could be added as a capabilities header minor version hint, with a finer grain of capability advertisement than then 1.x style of 1/2/3/4/etc offers. A lot of the things we want to do are use-case specific wants/needs. I simply want the thing calling itself HTTP/2.0 to state "X,Y,Z are REQUIRED". That is all. When we have a choice to specify something optional elsewhere lets do so. AYJ Afterword: WG editors; that opinion goes for the HTTPbis drafts final arrangement choices as well.
Received on Monday, 16 July 2012 01:44:10 UTC