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

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 11 Jan 2013 15:05:51 -0500

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/

---

From: Tim Bray <[email-masked]>
Date: Fri, 11 Jan 2013 12:18:34 -0800

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 <[email-masked]>wrote:

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

---

From: James M Snell <[email-masked]>
Date: Fri, 11 Jan 2013 12:20:56 -0800

+1, many times over.

On Fri, Jan 11, 2013 at 12:18 PM, Tim Bray <[email-masked]> wrote:

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

---

From: Martin Thomson <[email-masked]>
Date: Wed, 16 Jan 2013 16:45:22 -0800

> Something that looks more like CoAp/Core than the HTTP/2.0 proposals.

I also disagree.  If you desire a feature set that another protocol
provides, you are free to use that protocol.

---

From: Greg Wilkins <[email-masked]>
Date: Thu, 24 Jan 2013 13:42:19 +1100

> protocol, perhaps it would be better to do that with Web Services as well.

-1

It is already extremely difficult that we have to run at least 3 families
of framing protocols, with many version varieties over ports 80/443:   HTTP
(0.9, 1.0, 1.1), Websocket (pre RFC and post), SPDY (v2, v3)   and soon
HTTP/2.0

I'd like to see the future of port 80/443 to be convergence of framing
protocols rather than divergence.   Specifically I would like to see that
rather than send the websocket semantic over its own framing layer that
HTTP/2.0 will be able to provide a framing layer that will satisfy both
HTTP and websocket semantics.

If webservices cannot be catered for by either of those semantics (and I
have my doubts as I think muxed HTTP is a pretty good match), then perhaps
there could be an argument to propose another semantic to be carried by the
same framing layer.

Note that one of the attractive features of Microsofts counter proposal to
SPDY as the basis of HTTP/2.0 was that it used the websocket framing layer
as the basis for a HTTP semantic binding.    I fully accept that we have to
upgrade 80/443 from HTTP/1.x framing to something else, but let's make that
something else support all the semantics we need rather than reinventing
framing for each and every messaging semantic.

regards

-- 
Greg Wilkins <[email-masked]>
http://www.webtide.com
Developer advice and support from the Jetty & CometD experts.
Intalio, the modern way to build business applications.

---

From: Grahame Grieve <[email-masked]>
Date: Thu, 24 Jan 2013 03:18:50 +0000

Hi Tim

> onto my RESTful-app-construction needs.

well, here's an issue I have. What error code should an http server return if
a proposed update is not suitable because of the content of the submission?
There's nothing wrong at the http layer - it passes authenticaion, currency
and content type checks, and parses, ok. But there's something in the content
that violates server business rules. Something like trying to submit and
order with an identifier that has already been used, for example.

What would be right http status code to use? It's a client error, right?
The nearest appropriate status code would be 422, but I'm not sure
whether that can be used outside webdav. Either way, there's a bunch
of things I would expect in an application exchange protocol that don't
map that well.

I don't think that a different protocol is a good idea, but the discussion of
what's planned for HTTP/2 seems very focused on browsers & the web to
me, and doesn't seem to me to adequately consider the huge use that
exists for application/application communications

Grahame

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 24 Jan 2013 10:20:57 -0500

If people don't want there to be two different families then I think the
header compression needs to be totally rethunk.

I do not want to have a compression library in my Web Services. Too much
code bloat and more importantly, too much memory overhead and too much CPU.

If we want to have a single protocol then maybe what we should be thinking
of is using the coap codes as the starting point for header tokenization.

---

From: Julian Reschke <[email-masked]>
Date: Thu, 24 Jan 2013 16:30:00 +0100

> whether that can be used outside webdav. Either way, there's a bunch

It can.

> exists for application/application communications

Augmenting error handling for web services is an interesting topic. See 
prior proposals about Link relations, or a JSON typed response body 
format for 4xx/5xx.

All of this can be done in HTTP/1.1 and doesn't require any protocol 
changes.

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Thu, 24 Jan 2013 16:40:19 +0100

On 2013-01-24 16:20, Phillip Hallam-Baker wrote:
> If we want to have a single protocol then maybe what we should be
> thinking of is using the coap codes as the starting point for header
> tokenization.
> ...

As a matter of fact, figuring out the header field serialization is one 
of the current HTTP/2 related topics the WG discusses. See the various 
proposals and test suites.

Best regards, Julian

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 24 Jan 2013 10:48:06 -0500

On Thu, Jan 24, 2013 at 10:40 AM, Julian Reschke <[email-masked]>wrote:

> As a matter of fact, figuring out the header field serialization is one of
> the current HTTP/2 related topics the WG discusses. See the various

Yes and the SDPY proposal is what prompted my proposal to split the
protocols.

SPDY is hyper optimized for Web Browsing to the total exclusion of all
other concerns. I would like a simpler mechanism for parsing headers. SPDY
is a lot more complex.

I am not very interested in the relative packing efficiency of a class of
algorithms I don't want. I don't care how many bytes the compression saves
on the wire if it requires me to pipeline my messages through a compression
library.

Anything that involves hash functions is going to be a non starter as far
as I am concerned.

---

From: Julian Reschke <[email-masked]>
Date: Thu, 24 Jan 2013 16:55:04 +0100

On 2013-01-24 16:48, Phillip Hallam-Baker wrote:
>
>
> On Thu, Jan 24, 2013 at 10:40 AM, Julian Reschke <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     As a matter of fact, figuring out the header field serialization is
>     one of the current HTTP/2 related topics the WG discusses. See the
>     various proposals and test suites.
>
>
> other concerns. I would like a simpler mechanism for parsing headers.
> SPDY is a lot more complex.

SPDY is being used as input for the design of HTTP/2.0. One part that 
*will* be different is the header field format.

> I am not very interested in the relative packing efficiency of a class
> of algorithms I don't want. I don't care how many bytes the compression
> saves on the wire if it requires me to pipeline my messages through a
> compression library.
>
> Anything that involves hash functions is going to be a non starter as
> far as I am concerned.

Then I would recommend that you participate in the discussion about that 
format; that's why we're having it.

Best regards, Julian

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 24 Jan 2013 11:18:31 -0500

> format; that's why we're having it.

Which is exactly what I was doing

And I have been more than active in this conversation for your comments to
be rather patronizing.

I thought that the conversation was taking HTTP2.0 to a place that I think
incompatible with good Web Services practice. People assured me that they
want one protocol. I then stated that if they want one protocol the
conversation is going in the wrong direction.

I don't care how you polish the compression scheme, it is still going to be
a compression scheme.

---

From: Julian Reschke <[email-masked]>
Date: Thu, 24 Jan 2013 17:25:33 +0100

> Which is exactly what I was doing

I didn't have that impression. Sorry.

> ...
> And I have been more than active in this conversation for your comments
> to be rather patronizing.
>
> I thought that the conversation was taking HTTP2.0 to a place that I
> think incompatible with good Web Services practice. People assured me
> that they want one protocol. I then stated that if they want one
> protocol the conversation is going in the wrong direction.
>
> I don't care how you polish the compression scheme, it is still going to
> be a compression scheme.
> ...

IMHO: if HTTP/2 turns out to be something that can't be used with "web 
services", then we have screwed up things royally.

That being said: can you clarify what you understand as "web service", 
and how exactly it differs from a browser scenario? That would be 
helpful to understand your concern.

BTW: I'm also not a big fan of introducing too much complexity into the 
header representation; I think there's a consensus that that new 
complexity needs to be justified by what we gain from it.

Best regards, Julian

---

From: William Chan (陈智昌) <[email-masked]>
Date: Thu, 24 Jan 2013 09:34:26 -0800

I think SPDY is simpler for parsing headers in comparison to HTTP/1
except for the compression part. Would you agree? Patrick has written
up a good comparison here:
http://blog.jgc.org/2012/12/speeding-up-http-with-minimal-protocol.html#c5703739431744738432.

Can you clarify what exactly bothers you about piping your messages
through a compression library? There are clearly some concerns, but I
want to hear what specifically bothers you.

On Thu, Jan 24, 2013 at 7:48 AM, Phillip Hallam-Baker <[email-masked]> wrote:
> SPDY is hyper optimized for Web Browsing to the total exclusion of all other
> concerns. I would like a simpler mechanism for parsing headers. SPDY is a
> lot more complex.
>
> Anything that involves hash functions is going to be a non starter as far as
> I am concerned.
>
> --

---

From: Nico Williams <[email-masked]>
Date: Thu, 24 Jan 2013 11:46:21 -0600

> code bloat and more importantly, too much memory overhead and too much CPU.

I'd rather we didn't seek stateful compression schemes at all...  That
aside, stateful compression needs to be something that either side of
a connection (client, proxy, server, whatever) can refuse to do, in
which case your implementation needn't implement compression.

> If we want to have a single protocol [...]

We definitely should want to have a single protocol.

Nico
--

---

From: Nico Williams <[email-masked]>
Date: Thu, 24 Jan 2013 11:48:56 -0600

On Thu, Jan 24, 2013 at 9:30 AM, Julian Reschke <[email-masked]> wrote:
> [...]
> prior proposals about Link relations, or a JSON typed response body format
> for 4xx/5xx.

I've seen APIs that handle errors in JSON-encoded response bodies,
including one that always returns success in HTTP but errors in the
response body, which is kinda weird, but if none of the HTTP status
codes make sense...  (that was the author's defense).

Nico
--

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 24 Jan 2013 12:49:23 -0500

> want to hear what specifically bothers you.

The main one is that the receiver has to have enough memory to store the
dictionary.

That in turn means that the sender has to know whether the receiver has
enough space which in turn means that they have to have some way of
negotiating the dictionary size if the result is going to be reliable.

As currently specified, SPDY makes no sense to me because the first step in
SPDY is to essentially short circuit any intermediary or proxy by layering
over SSL. So now we have a Web browser talking directly to the Web Server.
So

1) Every header that has to do with intermediaries just became irrelevant
2) There is no reason that the client should send cookies on any request
after the first
3) The content preferences of a browser are unlikely to change either

Seems to me like delta encoding of the header set and converting well known
headers to tokens is all we need. Coap has already done this work.

---

From: Nico Williams <[email-masked]>
Date: Thu, 24 Jan 2013 11:42:27 -0600

On Wed, Jan 23, 2013 at 8:42 PM, Greg Wilkins <[email-masked]> wrote:
> It is already extremely difficult that we have to run at least 3 families of
> framing protocols, with many version varieties over ports 80/443:   HTTP
> HTTP/2.0 will be able to provide a framing layer that will satisfy both HTTP
> and websocket semantics.
>

Be careful about multiplexing different qualities of traffic over a
single TCP connection.  You don't want to have the SSHv1 flow control
problems all over again.  You also don't want to replicate SSHv2's
answer to those problems.

Basically, you should want one connection for bulk-ish traffic, and
one for non-bulk-ish traffic.  Else bad.

Nico
--

---

From: Roberto Peon <[email-masked]>
Date: Thu, 24 Jan 2013 10:35:41 -0800

I think your objections to using SSL are something I'm finding difficult to
understand. You don't like it that SSL cuts off man-in-the-middles?
SSL doesn't prevent a proxy, by the way, it simply requires that one is
configured explicitly instead of being implicit.

I'm also confused that you're advocating both keeping no state and keeping
state (e.g. cookies) at the same time?
-=R

On Thu, Jan 24, 2013 at 9:49 AM, Phillip Hallam-Baker <[email-masked]>wrote:

>
>
> On Thu, Jan 24, 2013 at 12:34 PM, William Chan (陈智昌) <
> [email-masked]> wrote:
>
> As currently specified, SPDY makes no sense to me because the first step
> in SPDY is to essentially short circuit any intermediary or proxy by
> layering over SSL. So now we have a Web browser talking directly to the Web
> Server. So
>
> Seems to me like delta encoding of the header set and converting well
> known headers to tokens is all we need. Coap has already done this work.
>
>
> --

---

From: William Chan (陈智昌) <[email-masked]>
Date: Thu, 24 Jan 2013 10:41:18 -0800

On Thu, Jan 24, 2013 at 9:49 AM, Phillip Hallam-Baker <[email-masked]> wrote:
>
>
> On Thu, Jan 24, 2013 at 12:34 PM, William Chan (陈智昌) <[email-masked]>
> wrote:
>>

I think this boils down to the argument on the other thread. Do the
gains for keeping state outweigh the costs? Note that given Roberto's
delta compression proposal, the sender can disable compression
entirely, so the receiver does not need to maintain state. Browsers
probably would not do this, due to our desire to optimize for web
browsing speed. For web services where you control the client, you
indeed would be able to disable compression.

> over SSL. So now we have a Web browser talking directly to the Web Server.

Just to be exact, SPDY does not mandate SSL. Current browsers that
support SPDY (Firefox and Chromium) only use it over SSL by default.

> headers to tokens is all we need. Coap has already done this work.

Note that the SPDY4 proposal is to use delta encoding which should
look like http://tools.ietf.org/html/draft-rpeon-httpbis-header-compression-00.
And James has his
http://tools.ietf.org/html/draft-snell-httpbis-bohe-00 proposal for
optimizing the well known headers. Do you disagree with the direction
here?

---

From: Nico Williams <[email-masked]>
Date: Thu, 24 Jan 2013 13:01:11 -0600

> indeed would be able to disable compression.

IMO we need stateful compression to be absolutely optional to
implement.  (If we choose to go with stateful compression in the first
place.  I think we shouldn't.)

Nico
--

---

From: Julian Reschke <[email-masked]>
Date: Thu, 24 Jan 2013 20:05:22 +0100

> codes make sense...  (that was the author's defense).

Bad defense, because it still can be classified either as 400 or 500.

2xx is the wrong choice, and I'll not go into the why over here 
(hopefully everybody knows!)

Best regards, Julian

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 24 Jan 2013 15:34:19 -0500

On Thu, Jan 24, 2013 at 12:48 PM, Nico Williams <[email-masked]>wrote:

> format

It makes perfect sense from a layering perspective.

In an RPC call I probably want HTTP errors to be strictly limited to
reporting network failures. 'entry not found' is a completely different
result from 'machine is down'

entry not found is arguably a successful transaction that returned an empty
list of results.

---

From: Julian Reschke <[email-masked]>
Date: Thu, 24 Jan 2013 21:54:11 +0100

On 2013-01-24 21:34, Phillip Hallam-Baker wrote:
>
>
> On Thu, Jan 24, 2013 at 12:48 PM, Nico Williams <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     On Thu, Jan 24, 2013 at 9:30 AM, Julian Reschke
>     <[email-masked] <mailto:[email-masked]>> wrote:
> entry not found is arguably a successful transaction that returned an
> empty list of results.

In that case you are (ab)using HTTP as transport protocol.

Best regards, Julian

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 24 Jan 2013 15:57:19 -0500

HTTP is a Session/Presentation Protocol

TCP is a Transport Protocol.

On Thu, Jan 24, 2013 at 3:54 PM, Julian Reschke <[email-masked]>wrote:

>> <mailto:[email-masked]>**> wrote:
>>
>>     <[email-masked] <mailto:[email-masked]>**> wrote:

---

From: Nico Williams <[email-masked]>
Date: Thu, 24 Jan 2013 15:22:24 -0600

> entry not found is arguably a successful transaction that returned an empty

That was the author's defense.

I understand Julian's objection too, but it made no difference.

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 25 Jan 2013 08:29:02 +1100

This sub-thread is getting mildly off-topic; if we start going down the rabbit hole of "what is an HTTP API?" (as dear as that subject is to my heart), I fear we'll never surface again.

Cheers,

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

---

From: Yoav Nir <[email-masked]>
Date: Thu, 24 Jan 2013 22:03:58 +0000

> place.  I think we shouldn't.)

I think we need to do a little more. I think we should define a "minimal implementation" and have a way for client and server to signal this. A minimal implementation would not be able to do any or some of these:
 - compression
 - server-initiated streams
 - stream priority
 - credentials
 - all but a small set of headers.
 - multiple concurrent streams

Maybe we need a CAPABILITIES control frame that will allow client or server to communicate to the other what capabilities they don't have.

A truly minimal client would be capable of one stream at a time - really down to HTTP/1.0 functionality with the new syntax.

Would this allow Phillip to use HTTP/2 for minimalist web services?

Yoav

---

From: Roberto Peon <[email-masked]>
Date: Thu, 24 Jan 2013 14:08:36 -0800

So... why would someone who didn't want these things use HTTP/2 instead of
HTTP/1?

-=R

On Thu, Jan 24, 2013 at 2:03 PM, Yoav Nir <[email-masked]> wrote:

> I think we need to do a little more. I think we should define a "minimal
> implementation" and have a way for client and server to signal this. A
> minimal implementation would not be able to do any or some of these:
>  - compression
> Maybe we need a CAPABILITIES control frame that will allow client or
> server to communicate to the other what capabilities they don't have.
>
> A truly minimal client would be capable of one stream at a time - really
> down to HTTP/1.0 functionality with the new syntax.
>

---

From: Nico Williams <[email-masked]>
Date: Thu, 24 Jan 2013 16:17:47 -0600

>  - multiple concurrent streams

As long as each can negotiate all-but-stateful-compression I'm happy.
I'd strongly object to having to forego the other things in order to
forego stateful compression.

Also, while we are this, IMO we should first produce minimal encodings
of headers and values where that's meaningful, *then* add optional
stateful compression.

> Maybe we need a CAPABILITIES control frame that will allow client or server to communicate to the other what capabilities they don't have.

Sure, but that's definitely something that had better have either
minimal encoding... or be statfully compressed.  Ugh.  Of course "no
state here" is a tiny -and therefore reasonable- amount of state.

> A truly minimal client would be capable of one stream at a time - really down to HTTP/1.0 functionality with the new syntax.

But that's not what I'm after.  I'm after the option to not implement
stateful compression.  I'm not saying the other things have to be
optional to implement -- I might, after further reading, but for now I
don't.

> Would this allow Phillip to use HTTP/2 for minimalist web services?

See my comment about minimal encodings.  Assuming we have that we'd
still have a sizeable improvement even without stateful compression,
and that would be a reason to want to use HTTP/2.0 without stateful
compression.

Nico
--

---

From: Yoav Nir <[email-masked]>
Date: Thu, 24 Jan 2013 22:19:50 +0000

It might end up smaller than what you need for an HTTP/1 client. But that also allows us to implement just one protocol on the server for both full-capability and minimal clients. Similarly for full-capabilities client working with minimal servers.

On Jan 25, 2013, at 12:08 AM, Roberto Peon <[email-masked]<mailto:[email-masked]>> wrote:

So... why would someone who didn't want these things use HTTP/2 instead of HTTP/1?

-=R

On Thu, Jan 24, 2013 at 2:03 PM, Yoav Nir <[email-masked]<mailto:[email-masked]>> wrote:

On Jan 24, 2013, at 9:01 PM, Nico Williams <[email-masked]<mailto:[email-masked]>> wrote:

> <[email-masked]<mailto:[email-masked]>> wrote:

Yoav

Email secured by Check Point

---

From: Roberto Peon <[email-masked]>
Date: Thu, 24 Jan 2013 14:23:33 -0800

That is the rub-- this forces complexity into every web-application by
forcing devlopers to have to do contingency and error cases for each
potentially optional parameter.
.. essentially, since people cannot rely upon it, they don't use it. This
happens today with HTTP/1 and it.. really sucks.

This doesn't seem like a good tradeoff when people who don't want these
things or the latency benefit can simply fall-back to HTTP/1

-=R

On Thu, Jan 24, 2013 at 2:19 PM, Yoav Nir <[email-masked]> wrote:

>  It might end up smaller than what you need for an HTTP/1 client. But that
> also allows us to implement just one protocol on the server for both
> full-capability and minimal clients. Similarly for full-capabilities client
> working with minimal servers.
>
>  On Jan 25, 2013, at 12:08 AM, Roberto Peon <[email-masked]> wrote:
>
>>  I think we need to do a little more. I think we should define a
>> "minimal implementation" and have a way for client and server to signal
>> this. A minimal implementation would not be able to do any or some of these:
>>  - compression

---

From: Roberto Peon <[email-masked]>
Date: Thu, 24 Jan 2013 14:25:28 -0800

And by "people who don't want" I mean implementors who don't wish to
implement the full-set of HTTP/2 features, even when many of them get out
of the way when you don't want 'em (e.g. the proposed compression stuff).
-=R

On Thu, Jan 24, 2013 at 2:23 PM, Roberto Peon <[email-masked]> wrote:

>>  It might end up smaller than what you need for an HTTP/1 client. But
>> that also allows us to implement just one protocol on the server for both

---

From: Nico Williams <[email-masked]>
Date: Thu, 24 Jan 2013 16:28:15 -0600

> So... why would someone who didn't want these things use HTTP/2 instead of

That's a misreading of what I wrote.

I want only the option to not implement stateful compression.  That's
all.  I still want all other HTTP/2.0 features.

Nico
--

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 24 Jan 2013 17:28:39 -0500

+1

What I want is to have the simplicity of coding the parser that comes from
being able to use a tokenized encoding. I do want to move away from text
headers but moving from there to a compression library would be total
nonsense for my applications.

Excluding the URI, my applications have four lines of headers. The way I do
compression is by not sending data I don't need.

I want to have better framing and streams etc. So there is a lot in HTTP 2
that would attract me but header compression is a show stopper no matter
how it is polished.

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 24 Jan 2013 17:36:43 -0500

So don't do header compression, do a tokenization approach that does not
cause Web Services to fork.

If Web Services can't use 2.0 then you have forked the protocol whether
they do that by continuing to use 1.1 or by developing a new protocol.

Not that there would be any difference in practice since if HTTP/2.0 does
not support Web Services in a sane fashion there will eventually be a 2.0
for Web Services.

We did know about compression libraries back in '92. Latency was a much
bigger concern back in those days when the whole of CERN was hanging off a
not much more than a T1 and we had 10base ethernet.

The idea of header compression was rejected back then as a silly
optimization and I really can't understand why anyone thinks the situation
has changed to make it less silly.

---

From: Roberto Peon <[email-masked]>
Date: Thu, 24 Jan 2013 14:46:28 -0800

Well, the web has changed a lot since its inception when pages were mostly
a single resource. Now, we're nearly fetching a 100 resources per page, and
myriad people make money from it.
I think that the decision to ignore compression in the beginning was a
correct one. Now, however, the headers are causing more than acceptable
latency impediments to page loads, especially on the devices which are
becoming the most prevalent (mobile devices with relatively high latency,
and low bandwidth).

I'm still confused about how what has been proposed would force WebServices
to fork.
Placing myself in your and Nico's imagined shoes, it still sounds like
forking would take more effort than taking someone's compression library
and hooking it in as appropriate, especially given that the overall memory
and CPU cost of doing so would be between negligible and zero.

Are you worried about devices with extremely limited code-space/memory?

-=R

On Thu, Jan 24, 2013 at 2:36 PM, Phillip Hallam-Baker <[email-masked]>wrote:

>>>> A truly minimal client would be capable of one stream at a time -
>>>> really down to HTTP/1.0 functionality with the new syntax.
>>>>

---

From: Nico Williams <[email-masked]>
Date: Thu, 24 Jan 2013 16:49:03 -0600

> has changed to make it less silly.

It has changed to make that less silly: web pages are now huge in
terms of discrete resources that have to be fetched.  Also, many, many
more users use the web, and they are less patient than CERN researches
might have been back when the web was a great, shiny new tool.

Nico
--

---

From: Roberto Peon <[email-masked]>
Date: Thu, 24 Jan 2013 14:53:41 -0800

Sorry to add to what I was saying:

The worst part is the high latency, especially given TCP's current
cogestion avoidance implementations-- the total number of round-trips ends
up dominating latency, regardless of how much bandwidth one has.

-=R

On Thu, Jan 24, 2013 at 2:46 PM, Roberto Peon <[email-masked]> wrote:

> I'm still confused about how what has been proposed would force
> WebServices to fork.
>>> .. essentially, since people cannot rely upon it, they don't use it.
>>> This happens today with HTTP/1 and it.. really sucks.
>>>

---

From: Nico Williams <[email-masked]>
Date: Thu, 24 Jan 2013 16:57:39 -0600

> Are you worried about devices with extremely limited code-space/memory?

Or extreme load.  Yes, I am.  If memory pressure on servers and middle
boxes results in higher connection turnover then we might well still
have a problem.

Nico
--

---

From: Roberto Peon <[email-masked]>
Date: Thu, 24 Jan 2013 15:01:02 -0800

Being one of the people who had to write mechanisms to make Google
reliable, I have the same concerns. That is why all of the features have
the ability to reduce stored state to zero, and also why I end up being
confused.
With really tiny devices, the size of the default dictionary is arguable
problematic given the code storage space. Otherwise, however, I don't know
that I could do substantially better--- the new compressor was designed
with proxies explicitly in mind, after all (the same to be said about the
flow control proposal that Will posted).

-=R

---

From: Nico Williams <[email-masked]>
Date: Thu, 24 Jan 2013 17:01:54 -0600

I mean, we have spent a great deal of effort over the last couple of
decades to minimize state in general, in TCP TCBs in particular, and
so on.  We've done that for a reason.

Also, there had better be a bound to stateful compression state size,
and therefore, deterministic synchronization or a synchronization
protocol (which would... add latency).

It's not at all obvious to me that stateful compression is a good
idea.  It is clear that only stateful compression can do something
about values that get repeated a lot, like cookies and URL prefixes,
but I'm not sure that's worth the trouble.

Nico
--

---

From: Roberto Peon <[email-masked]>
Date: Thu, 24 Jan 2013 15:04:48 -0800

> protocol (which would... add latency).

There is a bound, and the receiver (likely the server or proxy) gets to
decide what it is.

> but I'm not sure that's worth the trouble.

Is saving seconds on page-load times worth the trouble? I ask because that
is what we've seen in experiments...
-=R

---

From: "Robert Brewer" <[email-masked]>
Date: Thu, 24 Jan 2013 16:44:30 -0800

Roberto Peon wrote:
> The worst part is the high latency, especially given TCP's
> current cogestion avoidance implementations-- the total number
> of round-trips ends up dominating latency, regardless of how
> much bandwidth one has.

Why is this being addressed by trying to make the messages smaller? Wouldn't following the original architecture of HTTP, which was optimized for fewer, larger messages, also reduce latency?

Robert Brewer
[email-masked]

---

From: William Chan (陈智昌) <[email-masked]>
Date: Thu, 24 Jan 2013 16:49:53 -0800

http://lists.w3.org/Archives/Public/ietf-http-wg/2013JanMar/0357.html

---

From: Nico Williams <[email-masked]>
Date: Thu, 24 Jan 2013 18:53:12 -0600

> Why is this being addressed by trying to make the messages smaller? Wouldn't following the original architecture of HTTP, which was optimized for fewer, larger messages, also reduce latency?

This would require significant changes to HTML and web services.
HTTP/2.0 would be a much more transparent change.

Nico
--

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 24 Jan 2013 19:54:18 -0500

On Thu, Jan 24, 2013 at 7:44 PM, Robert Brewer <[email-masked]> wrote:

> Why is this being addressed by trying to make the messages smaller?
> Wouldn't following the original architecture of HTTP, which was optimized
> for fewer, larger messages, also reduce latency?
>

Well this all goes back to Tim's original point that maybe we should have
had more than 6 hours discussion before a grad student just threw in the
<IMG> tag because he thought it would be cool and Eric had already written
the code for images in the widget.

When we moved from one request per TCP session to multiple requests per TCP
session it was not exactly done well. Each request is still formatted as if
it was running in a separate session and so it has to reconstruct the whole
browser context.

I don't see why we could not do a delta encoding on the headers as follows

Old:

Get /foo
Header1:
Header2:
Header3:

Get /bar
Header1:
Header2:
Header3:

New:

Get /foo
Fred:[
Header1:
Header2:
Header3:
]

Get /bar
#include Fred

The client knows when headers are likely to be repeated across requests in
the same session - they are mostly repeats anyway.

---

From: William Chan (陈智昌) <[email-masked]>
Date: Thu, 24 Jan 2013 16:57:13 -0800

After reading Nico's reply, I realize I misunderstood your email.
Ignore my previous email.

---

From: William Chan (陈智昌) <[email-masked]>
Date: Thu, 24 Jan 2013 17:00:27 -0800

> I don't see why we could not do a delta encoding on the headers as follows

Why do you keep saying this as if it has not already been proposed for
HTTP/2 as I pointed out earlier? Please see
http://www.mnot.net/blog/2013/01/04/http2_header_compression.

---

From: Julian Reschke <[email-masked]>
Date: Fri, 25 Jan 2013 07:19:08 +0100

> entry not found is arguably a successful transaction that returned an

Machine is down is a network error (the HTTP request couldn't be sent). 
"not found" is a 404 (client error).

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Fri, 25 Jan 2013 07:20:17 +0100

> TCP is a Transport Protocol.

That's why I chose the term "abuse".

Best regards, Julian

---

From: Hassnaa Moustafa <[email-masked]>
Date: Mon, 28 Jan 2013 10:50:59 -0800

Hi,

I am just joining this discussion thread and I have a comment on what was
mentioned by William "precisely the following text - copied from William's
message below":

* I think we need to do a little more. I think we should define a "minimal
*

 Hassnaa: Is video streaming considered one of the services for which
HTTP2.0 could present a gain? or the focus right now is on web-browsing for
the minimal implementation.

Regards,
Hassnaa

---

From: Roberto Peon <[email-masked]>
Date: Tue, 29 Jan 2013 01:36:16 -0800

Yes, video streaming, depending on how it is done*, could benefit from some
of the features, especially prioritization...

*there are other protocols which are likely better suited to solving
video-specific problems.
-=R

On Mon, Jan 28, 2013 at 10:50 AM, Hassnaa Moustafa <
[email-masked]> wrote:

> * I think we need to do a little more. I think we should define a

---

From: Yoav Nir <[email-masked]>
Date: Tue, 29 Jan 2013 09:54:25 +0000

I think it's fairly certain that browsing web pages in the browser is the first class citizen here, and the page load times (relevant for web browsing) is the driver for the HTTP/2 effort.

There are other uses of HTTP:
 - web services
 - certificate RPs downloading CRLs or OCSP responses
 - media downloads / media streaming
 - software updates and downloads
 - Antivirus / IPS signature downloads
 - others

All these currently use HTTP and there's no reason for them to be "left behind" in HTTP/1.1. Some of SPDY's features, like server push and header compression are useless for most of these uses.

My goal in suggesting a minimal implementation definition is to allow implementers to create a small but compliant HTTP implementation that does not include all the bells and whistles, but can still get your software update to you. I think if we can get a 1000-2000 LoC C implementation of a simple fetcher can be written with compliant HTTP/2 support, that would be a good thing.

Yoav

On Jan 29, 2013, at 11:36 AM, Roberto Peon <[email-masked]<mailto:[email-masked]>>
 wrote:

Yes, video streaming, depending on how it is done*, could benefit from some of the features, especially prioritization...

*there are other protocols which are likely better suited to solving video-specific problems.
-=R

On Mon, Jan 28, 2013 at 10:50 AM, Hassnaa Moustafa <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

I am just joining this discussion thread and I have a comment on what was mentioned by William "precisely the following text - copied from William's message below":

 Hassnaa: Is video streaming considered one of the services for which HTTP2.0 could present a gain? or the focus right now is on web-browsing for the minimal implementation.

Regards,
Hassnaa

On Thu, Jan 24, 2013 at 2:19 PM, Yoav Nir <[email-masked]<mailto:[email-masked]>> wrote:
It might end up smaller than what you need for an HTTP/1 client. But that also allows us to implement just one protocol on the server for both full-capability and minimal clients. Similarly for full-capabilities client working with minimal servers.

-=R

Yoav