Subject: DRAFT: more details for HTTPtre

From: Mark Nottingham <[email-masked]>
Date: Tue, 28 Nov 2017 13:03:50 +1100

[ proposer, not Chair, hat on ]

In Singapore, it seems like there was broad acknowledgement that doing HTTPter is a good idea, but there was some concern about the schedule, especially since QUIC might depend upon or interact with it. 

I think this work would go something like this:

* draft-00: Copy of RFC723X for future diffs
* draft-01: Update references, incorporate errata
* draft-02: Re-organise to put all HTTP/1.1-specific information in one draft, remaining architectural content from RFC7230 into RFC7231's draft
* draft-03: Start addressing issues, adding text about abstract model
* [further drafts as needed]

I think we can get to the draft-03 milestone above in a matter of 2-3 months, and cap ourselves at say six months beyond that.

The intent here is to end up with something like this set of documents:

a) HTTP Architecture and Core Semantics - currently parts of RFC7230, all of 7231, plus more text on abstractions
b) HTTP/1.1  - connection management, mapping to TCP transport
c) HTTP Conditional Requests
d) HTTP Range Requests
e) HTTP Caching
f) HTTP Authentication

We *can* combine (c) (d), (e), and (f) into (a), but for simplicity's sake I think we should at least start by keeping them apart.

Does this seem reasonable?

> On 11 Oct 2017, at 2:43 am, Mark Nottingham <[email-masked]> wrote:
> 
> Hi everyone,
> 
> We've talked about revising the HTTP/1.1 documents a few times; I think the next step is to agree on a scope of work. See draft proposal below.
> 
> --->8---
> 
> The Working Group will revise the RFC723[0-5] document set. The primary goals of this work will be:
> 
> 1)  To clearly separate the version-dependent aspects of HTTP from those that are version-independent, to aid readers and implementers, and assist definition of future protocol versions;
> 
> 2) Clarifying HTTP's underlying abstractions and guarantees (the "abstract model" of HTTP), to define a target for future versions of the protocol;
> 
> 3) Incorporating errata;
> 
> 4) Clarifying how HTTP is extended and versioned, as necessary; and
> 
> 5) Addressing significant (as determined by the Chairs) security and interoperability issues that are raised.
> 
> Issues that are specific to HTTP/1.1 (e.g., chunked encoding, connection handling) will only be addressed if there is broad (as determined by the Chairs) implementation support for doing so.
> 
> The number and focus of the resulting documents might be the same, or might differ. It is expected that the resulting documents will be suitable for publication as Internet Standard. 
> 
> ---8<---

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

---

From: Willy Tarreau <[email-masked]>
Date: Tue, 28 Nov 2017 07:07:25 +0100

Hi Mark,

On Tue, Nov 28, 2017 at 01:03:50PM +1100, Mark Nottingham wrote:
(...)
> We *can* combine (c) (d), (e), and (f) into (a), but for simplicity's sake I
> think we should at least start by keeping them apart.
> 

All this seems reasonable to me. However, I'd purposely move b) to the
end of the list, to ensure that we have a whole set of version-agnostic
documents and that only the last one has to be swapped with whatever we
want for the transport.

We should also take a look at 7540/7541 as there are a few references
to 1.1 when it comes to gateways, which means to me that some elements
might be missing in the semantics part (eg: cookie header concatenation
probably, and stuff like this).

Regards,
Willy

---

From: Julian Reschke <[email-masked]>
Date: Tue, 28 Nov 2017 07:42:37 +0100

> * draft-00: Copy of RFC723X for future diffs

+1

> * draft-01: Update references, incorporate errata

+1

> * draft-02: Re-organise to put all HTTP/1.1-specific information in one draft, remaining architectural content from RFC7230 into RFC7231's draft

Not convinced yet that merging the remainder of RFC 7231 with RFC 7232 
is a good thing....

> * [further drafts as needed]

Where I'm not sure whether we want to address *everything* that's 
currently sitting in github issues. Some of this would require changing 
our strategy with respect to handling malformed messages...

> We *can* combine (c) (d), (e), and (f) into (a), but for simplicity's sake I think we should at least start by keeping them apart.

Let's keep them apart at the beginning. We may want to analyze how much 
they cross-reference each other, and then decide on a per document basis.

> Does this seem reasonable?

Yes.

Best regards, Julian

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 28 Nov 2017 17:44:08 +1100

> On 28 Nov 2017, at 5:42 pm, Julian Reschke <[email-masked]> wrote:
> 
> Not convinced yet that merging the remainder of RFC 7231 with RFC 7232 is a good thing....

I think that's a preliminary approach we could try; we'll only know after we do.

> Where I'm not sure whether we want to address *everything* that's currently sitting in github issues. Some of this would require changing our strategy with respect to handling malformed messages...

Agreed; many issues will be closed with no action (see previous message about scope).

> Let's keep them apart at the beginning. We may want to analyze how much they cross-reference each other, and then decide on a per document basis.

+1

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Tue, 28 Nov 2017 08:48:05 +0000

--------
In message <[email-masked]>, Mark Nottingham writes:

>In Singapore, it seems like there was broad acknowledgement that doing 
>HTTPter is a good idea, but there was some concern about the schedule, 
>especially since QUIC might depend upon or interact with it. 

How about we call it HTTP3 instead, and focus on all the stuff that
can or should be removed, in order to reduce implementation complexity,
privacy concerns and efficiency ?

To give one example:

The pervasive wiretapping by NSA+friends which got IETF all hot and
bothered.

But NSA+friends are at least in theory under some kind of public
oversight, and generally focused only on their charter goals.

For comparison HTTP Cookies are used to invade the privacy of every
single person on the planet, by any number of large transnational
tax-evading companies, by any method which will bring them a profit.

Whatever "oversight" the shareholders exercise, is all focused on
increasing that profit, because the shareholders are mainly
tax-sheltered transnational funds, which invest purely to make a
profit.

In QUIC there should be no Cookies, but instead a client chosen
session identifier, so that clients get a real, rather than a pretend
"private browsing" choice.

As a side effect, replacing many kilobytes of fatty cookies with
a 128 or even 256 bit session identifier will save tons of
bandwidth and processing power.

Poul-Henning

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
[email-masked]         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

---

From: Julian Reschke <[email-masked]>
Date: Tue, 28 Nov 2017 10:10:12 +0100

> privacy concerns and efficiency ?

That sounds to be very different task to do.

> ...

Well, cookies aren't even defined in the specs we're planning to revise 
as part of this activity...

Best regards, Julian

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Tue, 28 Nov 2017 10:00:54 +0000

--------
In message <[email-masked]>, Julian Reschke writes

>as part of this activity...

Which is good, because that means we could ban them from H3...

---

From: Lucas Pardue <[email-masked]>
Date: Tue, 28 Nov 2017 11:20:38 +0000

Hi Mark,

I'll pose a different question sorry.

Having recently spent a bit of time reading "newer" HTTP related documents, there seem to be a few concepts that are growing from a HTTP/2 root and describe themselves as an HTTP/2 semantic, for example, server push or header compression.

I have also been reading the HTTP/QUIC mapping again, and digesting it. I've come to the opinion (shared with some others) that this is most certainly not HTTP/2 over QUIC. This subtlety is sometimes hard to articulate or maintain, especially given the legacy of gQUIC and earlier mapping documents. This seems to mirror some of the issues related to HTTP/1.1 vs HTTP that the proposed changes would attempt to address.

So I guess the question I have is, is there any appetite to extract out of HTTP/2 any common semantic that could apply to HTTP/QUIC or HTTP/next?

Note, Alt-Svc seems to have avoided the issue I describe. The separation of HTTP/2 and HTTP/QUIC extension spaces will allow for a new ALTSVC frame to be coined cleanly, rather than muddled by HTTP/2 luggage. In contrast, I find something like RFC 8030 (Generic Event Delivery Using HTTP Push) gets caught up in the HTTP/2 trap.

Kind regards
Lucas
________________________________________
From: Mark Nottingham [[email-masked]]
Sent: 28 November 2017 02:03
To: HTTP Working Group
Cc: Patrick McManus
Subject: DRAFT: more details for HTTPtre

-----------------------------
http://www.bbc.co.uk
This e-mail (and any attachments) is confidential and
may contain personal views which are not the views of the BBC unless specifically stated.
If you have received it in
error, please delete it from your system.
Do not use, copy or disclose the
information in any way nor act in reliance on it and notify the sender
immediately.
Please note that the BBC monitors e-mails
sent or received.
Further communication will signify your consent to
this.
-----------------------------

---

From: Ilari Liusvaara <[email-masked]>
Date: Tue, 28 Nov 2017 14:00:08 +0200

On Tue, Nov 28, 2017 at 11:20:38AM +0000, Lucas Pardue wrote:
> 
> Having recently spent a bit of time reading "newer" HTTP related
> documents, there seem to be a few concepts that are growing from a
> HTTP/2 root and describe themselves as an HTTP/2 semantic, for
> example, server push or header compression.

Server push is a new semantic in HTTP. But header compression is
supposed to be internal matter of HTTP/2.

Another new concept in HTTP/2 is connection coalescing. And HTTP/2
also allows for variety of extensions containing new semantics.

> I have also been reading the HTTP/QUIC mapping again, and digesting
> it. I've come to the opinion (shared with some others) that this is
> most certainly not HTTP/2 over QUIC.

Yes. Running HTTP/2 framing layer on top of QUIC definitely does not
work. The most obvious problem is header compression not working.
 
> So I guess the question I have is, is there any appetite to extract
> out of HTTP/2 any common semantic that could apply to HTTP/QUIC or
> HTTP/next?

Server push, maybe?

-Ilari

---

From: Lucas Pardue <[email-masked]>
Date: Tue, 28 Nov 2017 16:52:05 +0000

Hi Ilari,

Ilari Liusvaara wrote:

> Server push is a new semantic in HTTP. But header compression is supposed
> to be internal matter of HTTP/2.
> 

I do agree that header compression is "opaque" to an HTTP application.

So slight slip of the tongue from me perhaps, my intention was to say that the concept of HTTP Header compression, in terms of something " ... that eliminates redundant header fields, limits vulnerability to known security attacks, and has a bounded memory requirement.", is maybe generally applicable to future versions of HTTP. 

RFC 7540 Section 4.3 describes both a generic definition of compression (header list serialisation into a header block) and specific implementation detail (use HPACK, carry header blocks in HEADERS or PUSH_PROMISE). While it could be possible to extract the generic definition I am not currently sure how useful that would be.

To risk stoking flames even further. It could be argued that HPACK has little that ties it to HTTP/2. It defines some SETTINGS to control dynamic table size, references HTTP/2 pseudo header fields, and has some implicit requirements of connection usage and delivery guarantees. 

> Another new concept in HTTP/2 is connection coalescing. And HTTP/2 also
> allows for variety of extensions containing new semantics.

HTTP connection coalescing is another good example, thanks for picking that out.

Regards
Lucas

---

From: Mike Bishop <[email-masked]>
Date: Tue, 28 Nov 2017 18:32:15 +0000

I agree that HPACK is largely decouplable from HTTP/2, or HTTP.  The core of the protocol is a general-purpose compression algorithm for streaming key-value dictionaries, rather than straight text.  The pieces that bind it to H2 are incidental, and perhaps we could have structured it differently.

Coalescing isn't a new semantic -- each HTTP mapping defines how parallelism and connection reuse should work in that mapping.  HTTP/2 simply happens to define it more expansively than HTTP/1.1.

-----Original Message-----
From: Lucas Pardue [mailto:[email-masked]] 
Sent: Tuesday, November 28, 2017 8:52 AM
To: [email-masked]
Cc: Mark Nottingham <[email-masked]>; HTTP Working Group <[email-masked]>; Patrick McManus <[email-masked]>
Subject: RE: DRAFT: more details for HTTPtre

Hi Ilari,

Regards
Lucas

---

From: Mike Bishop <[email-masked]>
Date: Tue, 28 Nov 2017 18:36:30 +0000

Sounds like a plan, but +1 to Julian's comment that this is a document clean-up effort that will require many of the current issues (and PHK's stripped-down dreams) to be postponed to a different context or closed with no action.

But is it "ter" or "tre"?  We have to get important details like this nailed down.  😉

-----Original Message-----
From: Mark Nottingham [mailto:[email-masked]]
Sent: Monday, November 27, 2017 6:04 PM
To: HTTP Working Group <[email-masked]>
Cc: Patrick McManus <[email-masked]>
Subject: DRAFT: more details for HTTPtre

d) HTTP Range Requests

e) HTTP Caching

f) HTTP Authentication

> On 11 Oct 2017, at 2:43 am, Mark Nottingham <[email-masked]<mailto:[email-masked]>> wrote:

--

---

From: Willy Tarreau <[email-masked]>
Date: Wed, 29 Nov 2017 08:17:49 +0100

On Tue, Nov 28, 2017 at 06:32:15PM +0000, Mike Bishop wrote:
> I agree that HPACK is largely decouplable from HTTP/2, or HTTP.  The core of
> the protocol is a general-purpose compression algorithm for streaming
> key-value dictionaries, rather than straight text.  The pieces that bind it
> to H2 are incidental, and perhaps we could have structured it differently.

I think there are just a few points raised following HPACK that deserve
being mentionned in httpter for future designs, and it would be good to
have a "header compression" section to centralize them. We at least had
to accept that :
  - cookies can be sent as individual header fields and have to be folded
    using "; " unlike other headers using ", ".
  - leading and trailing LWS in values are dropped (since compression
    removes them before looking up values in dictionnaries)
  - status reason is dropped
  - header field names case is changed along the path
  - header field names cannot contain a colon
  - quite a number of header field values belong to a well known set

I know that these ones result from protocol properties that we already
know, but by definition, compression tries to make efficient use of known
properties and tend to exploit them all at once. As a result, non-compliant
implementations tend to be much more stressed by compression than by usual
traffic. And in addition it should encourage more compression-friendly
improvements over time.

Willy

---

From: Lucas Pardue <[email-masked]>
Date: Thu, 30 Nov 2017 10:12:45 +0000

Hi Mike,

The connection coalescing case is interesting as it's not currently described in HTTP/QUIC. Presumably by oversight or time constraint rather than intent. (We've got a ticket open tracking that one.)

Changing track, I've just seen your SNI I-D
https://tools.ietf.org/html/draft-bishop-httpbis-sni-altsvc-00

References to Frames don't state a specific mapping (HTTP/2 or HTTP/QUIC). Reading between the lines this seems intentional, which got me thinking that also Frames could be described as a new HTTP semantic for binary-capable wire formats.

Lucas
________________________________________
From: Mike Bishop [[email-masked]]
Sent: 28 November 2017 18:32
To: Lucas Pardue; [email-masked]
Cc: Mark Nottingham; HTTP Working Group; Patrick McManus
Subject: RE: DRAFT: more details for HTTPtre

---

From: Amos Jeffries <[email-masked]>
Date: Fri, 1 Dec 2017 05:04:40 +1300

> References to Frames don't state a specific mapping (HTTP/2 or HTTP/QUIC). Reading between the lines this seems intentional, which got me thinking that also Frames could be described as a new HTTP…

The HTTP/1 message format is also conceptually interpreted as one or 
more Frames consisting of request-line, status-line, mime, and payload 
chunks. Which have to be sent in a specific order when sent. The mime 
and payload being optional depending on details in the first line.

RFC 7230 even starts describing the details that delimit those areas (in 
particular the payload) in terms of "framing".

Amos