W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2013

Re: Should Web Services be served by a different HTTP n+1?

From: Tim Bray <tbray@textuality.com>
Date: Fri, 11 Jan 2013 12:18:34 -0800
Message-ID: <CAHBU6iu-bH_cEEVNq0CxcHZELjAFZ0Vb6d8cN5y_qbmu6xCKFg@mail.gmail.com>
To: Phillip Hallam-Baker <hallam@gmail.com>
Cc: "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
I disagree strenuously.  The semantics of HTTP as they are today map well
onto my RESTful-app-construction needs.  In particular: dispatching on
content-type, the use of standard caching stuff, also if-modified-since and
(especially) ETags.  -T

On Fri, Jan 11, 2013 at 12:05 PM, Phillip Hallam-Baker <hallam@gmail.com>wrote:

> Taking a look at the discussion here on HTTP 2.0, it seems to be very
> focused on the needs of browsers and less responsive to the needs of Web
> services.
> Now it is pretty clear that port 80/443 is going to have to support both
> sets of use cases and Web Services have to tolerate being molested by
> intermediaries trying to address Web browser considerations. But other than
> that, the two sets of use cases seem pretty disjoint to me. We have already
> hived off Web Sockets as what is essentially a completely different
> protocol, perhaps it would be better to do that with Web Services as well.
> My Web Services have a need for some sort of framing and I would really
> prefer to do it above the level of the protocol so that there is a standard
> interface that things like firewalls can understand.
> But I can't see a use for content types in Web Services, let alone header
> compression and the things being considered for HTTP/2.0. The header frame
> I need is just not that big, my ideal needs are:
> Request:
> * Method + URI
> * Framing data (chunked / content length)
> * Authentication data
> Response
> * Response code
> * Framing data (chunked / content length)
> * Do not cache flag
> * Authentication data
> I don't use any of the rest of the data and in fact I don't want to
> either. I deliberately discard it in my applications because I don't want
> the core of the code seeing data that has not been authenticated.
> Metadata is really important where there is a possibility it might change.
> But I don't give implementers the option of any other charset than UTF-8
> and if there is a choice of syntax there will be different web service
> endpoints for each one.
> So as far as I am concerned, I would like there to be a HTTP/2.0 for Web
> Services but it is probably one that is a lot, lot smaller than 1.1.
> Something that looks more like CoAp/Core than the HTTP/2.0 proposals.
> --
> Website: http://hallambaker.com/
Received on Friday, 11 January 2013 20:19:02 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:09 UTC