Subject: Re: Straw-man for our next charter

From: Larry Masinter <[email-masked]>
Date: Fri, 27 Jul 2012 23:39:01 -0700

re changes to semantics: consider the possibility of eliminating "sniffing" in HTTP/2.0. If sniffing is justified for compatibility with deployed servers, could we eliminate sniffing for 2.0 sites?

It would improve reliability, security, and even performance. Yes, popular browsers would have to agree not to sniff sites running 2.0, so that sites wanting 2:0 benefits will fix their configuration.

Likely there are many other warts that can be removed if there is a version upgrade.

-----Original message-----
From: Mark Nottingham <[email-masked]>
To: Amos Jeffries <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Sent: Fri, Jul 27, 2012 06:16:31 GMT+00:00
Subject: Re: Straw-man for our next charter

On 27/07/2012, at 4:10 PM, Amos Jeffries <[email-masked]> wrote:

> On 27/07/2012 5:27 p.m., Mark Nottingham wrote:
>> Hi Amos,
>>
>> On 25/07/2012, at 10:02 PM, Amos Jeffries <[email-masked]> wrote:
>>>> Work will begin using XXX as a starting point; all proposals are to be expressed
>>>> in terms of changes to the that document.
>>> I just think I'll throw a spanner in the general direction of the works here....
>>>
>>> How realistic is it to expect the HTTPbis 1.1 draft documents fill that role? At least we can guarantee that modifications to adjust them for 2.0 specifics will not loose or add any features unintentionally that could affect HTTP/1.1 compatibility.
>> I'm not sure what your concern is here...
>
> concern 1) is the feature parity between the HTTP/1 drafts and any other document that gets picked. ie workload to get the new doc completed.
>
> concern 2) is the politcal battle to get document X to meet the WG goals.
>
> Much like what I said in my expression of interest summary. The HTTP/2 drafts on the tables (own one included) do not come up to scratch for HTTP/2 starting points.
>
> I know a lot of people have interest in SPDY, but to make that the HTTP/2 base doc there are a fair chunk of things which will need pruning out - if only because they are new semantics. It is probably not a good idea for the WG to start off facing that political battle to ensure its semantically seamless to HTTP/1.1. The other documents are bare-bones with specific focus on framing improvement over WG drafts part1-2.

Aha. I was assuming that would come up; please discuss (details would help).

> However taking the HTTPbis draft documents and replacing sections of them with SPDY mechanisms, frame design, etc as we agree on particulars - that has a clear chance of faster success.

That's an interesting approach.

Cheers,

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

---

From: Amos Jeffries <[email-masked]>
Date: Sat, 28 Jul 2012 18:53:22 +1200

On 28/07/2012 6:39 p.m., Larry Masinter wrote:
> re changes to semantics: consider the possibility of eliminating 
> "sniffing" in HTTP/2.0. If sniffing is justified for compatibility 
> with deployed servers, could we eliminate sniffing for 2.0 sites?
>
> It would improve reliability, security, and even performance. Yes, 
> popular browsers would have to agree not to sniff sites running 2.0, 
> so that sites wanting 2:0 benefits will fix their configuration.
>

Which of the several meanings of "sniffing" are you talking about exactly?

AYJ

---

From: Larry Masinter <[email-masked]>
Date: Sat, 28 Jul 2012 08:01:08 -0700

The sniffing I was in particular hoping to stop is content-type sniffing.
http://tools.ietf.org/html/draft-ietf-websec-mime-sniff-03

" Many web servers supply incorrect Content-Type header fields with
   their HTTP responses.  In order to be compatible with these servers,
   user agents consider the content of HTTP responses as well as the
   Content-Type header fields when determining the effective media type
   of the response."

If browsers suddenly stopped sniffing HTTP/1.1 content, it would break existing web sites, so of course the browser makers are reluctant to do that.

However, if it was a requirement to supply a _correct_ content-type header for HTTP/2.0, and no HTTP/2.0 client sniffed, then sites upgrading to HTTP/2.0 would fix their content-type sending (because when they were deploying HTTP/2.0 they would have to in order to get any browser to work with them.)

Basically, sniffing is a wart which backward compatibility keeps in place. Introducing a new version is a unique opportunity to remove it. 

The improved performance would come from having to look at the content to determine before routing to the appropriate processor.

Larry

-----Original Message-----
From: Amos Jeffries [mailto:[email-masked]] 
Sent: Friday, July 27, 2012 11:53 PM
To: [email-masked]
Subject: Re: Straw-man for our next charter

AYJ

---

From: Adam Barth <[email-masked]>
Date: Sat, 28 Jul 2012 17:53:05 -0700

>From the charter:

---8<---
Changes to the existing semantics of HTTP are out of scope in order to
preserve the meaning of messages that might cross a 1.1 --> 2.0 --> 1.1
request chain.
--->8---

http://datatracker.ietf.org/wg/httpbis/charter/

Changing how user agents interpret the Content-Type header would change the
semantics of HTTP and are therefore out of scope for HTTP/2.0 according to
our current charter.

Adam

On Sat, Jul 28, 2012 at 8:01 AM, Larry Masinter <[email-masked]> wrote:

> If browsers suddenly stopped sniffing HTTP/1.1 content, it would break
> existing web sites, so of course the browser makers are reluctant to do
> that.
>
> However, if it was a requirement to supply a _correct_ content-type header
> for HTTP/2.0, and no HTTP/2.0 client sniffed, then sites upgrading to
> HTTP/2.0 would fix their content-type sending (because when they were
> deploying HTTP/2.0 they would have to in order to get any browser to work
> with them.)
>
> Basically, sniffing is a wart which backward compatibility keeps in place.
> Introducing a new version is a unique opportunity to remove it.
>
> The improved performance would come from having to look at the content to
> determine before routing to the appropriate processor.
>
> Larry
>
>

---

From: Mark Nottingham <[email-masked]>
Date: Sun, 29 Jul 2012 11:52:15 -0700

Sniffing -- for better or worse -- isn't really a HTTP behaviour. I.e., it may use a HTTP header (User-Agent), but it's more a use *of* HTTP -- just as Web browsing is generally.

Also -- and everyone really needs to understand this -- HTTP is NOT an end-to-end protocol, and therefore browsers can't tell whether or not it's a "2.0 site" because there may be intermediary transitions in the middle. 

As far as shaving warts off -- doing so in the protocol is really, really hard, because the deployed footprint is so large. My preferred approach is to allow sites to opt out -- e.g., <http://tools.ietf.org/html/draft-nottingham-http-browser-hints-00>.

Cheers,

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

---

From: "Adrien W. de Croy" <[email-masked]>
Date: Sun, 29 Jul 2012 22:59:42 +0000

We see this problem a lot at the gateway.  We have processing agents 
that only want to process say text/html, and really don't like getting 
streamed MP4s labelled as text/html by some brain-dead server

But in the end, where does the server get the C-T from?  Most just do a 
map lookup on file extension.

Even if we tried to push the meta-data into the resource itself, so it 
could be specified by the actual author (think about the hosted site, 
where the site maintainer has no control over content types the server 
will send, or not easily), then how do we trust that information?  Some 
attacker can label whatever content as whatever type if they can find 
some purpose to do so.

In the end, I think it basically makes Content-Type largely unreliable. 
  I don't see this changing with 2.0 (at least not properly), unless we 
introduce the concept of trust - either sign content by someone 
vouching for its type, or run RBLs of known bad servers.

Do we even need C-T if clients are sniffing anyway?

Adrien

---

From: Adam Barth <[email-masked]>
Date: Sun, 29 Jul 2012 17:11:26 -0700

On Sun, Jul 29, 2012 at 3:59 PM, Adrien W. de Croy <[email-masked]> wrote:
>
> We see this problem a lot at the gateway.  We have processing agents that
> only want to process say text/html, and really don't like getting streamed
> MP4s labelled as text/html by some brain-dead server
>
> But in the end, where does the server get the C-T from?  Most just do a map
> lookup on file extension.
>
> Even if we tried to push the meta-data into the resource itself, so it could
> be specified by the actual author (think about the hosted site, where the
> site maintainer has no control over content types the server will send, or
> not easily), then how do we trust that information?  Some attacker can label
> whatever content as whatever type if they can find some purpose to do so.
>
> In the end, I think it basically makes Content-Type largely unreliable.  I
> don't see this changing with 2.0 (at least not properly), unless we
> introduce the concept of trust - either sign content by someone vouching for
> its type, or run RBLs of known bad servers.
>

It's certainly used in an essential way in the web browser security
model.  In any case, I'm pretty sure this discussion is getting
off-topic.

Adam

---

From: Larry Masinter <[email-masked]>
Date: Sun, 29 Jul 2012 20:24:38 -0700

HTTP 2.0 can tighten requirements where loose interpretation in HTTP 1.x leads to performance, reliability, security problems.

For some areas (like pipelining) it would require browsers and other HTTP agents to implement MORE, and perhaps that isn't realistic.
But for sniffing, we would not be asking browsers to implement more, but rather to turn off heuristic interpretation.
So I think it's feasible and quite consistent with the goals and can meet the gateway requirements as well.

There's no need to sign content. There's just a need to for tooling to aid site owners into making their web sites "HTTP 2.0 ready".
That seems to require a variety of optimizations, anyway, so cleaning up content-type labels.

Perhaps this is just a matter of reversing the sense of the "nosniff" header, that is 2.0 defaults nosniff to true. 1.1 defaults to false. Gateways can just make it explicit.

-----Original Message-----
From: Adam Barth [mailto:[email-masked]] 
Sent: Sunday, July 29, 2012 5:11 PM
To: Adrien W. de Croy
Cc: Larry Masinter; [email-masked]
Subject: Re: Re[2]: Straw-man for our next charter

Adam

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Mon, 30 Jul 2012 07:23:32 +0000

In message <em704e4b8a-ca78-4787-810d-6b51e6587714@bombed>, "Adrien W. de Croy"

>Do we even need C-T if clients are sniffing anyway?

Actually not.

If we want maximum efficiency and lowest latency, the content should
always use some kind of efficiently compressed format for content.

Most A-V content do so already, and self-indentify as a result.

In fact, about the only content which does not automatically compress
is XML, HTML, CSS, ASCII and Javascript.

Unfortunately the readily available general purpose compression
standards only identify the compression algorithem and not the
content in the compressed bitstream.

But I think this would work:

	Remove the C-T header.

	Mandate that content be compresssed with a self-identifying
	compression.

	Mandate support for gzip compression of content, with an optional
	MIME type in the gzip "comment" header field.

The important detail that would make this work in practice, is
that GZIP has a no compression mode, where bytes are just framed
by other bytes, so in the rare case of a precompressed but not
self-identifying data type, gzip can provide the identification
without the overhead of repeated compression.

-- 
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: Adam Barth <[email-masked]>
Date: Mon, 30 Jul 2012 00:58:22 -0700

> HTTP 2.0 can tighten requirements where loose interpretation in HTTP 1.x leads to performance, reliability, security problems.

Where does the charter say that?  My reading of the charter is that
"changes to the existing semantics of HTTP are out of scope."

Adam

---

From: "Martin J. Dürst" <[email-masked]>
Date: Mon, 30 Jul 2012 17:05:33 +0900

Hello Adam,

On 2012/07/30 16:58, Adam Barth wrote:
> On Sun, Jul 29, 2012 at 8:24 PM, Larry Masinter<[email-masked]>  wrote:

That may well be the correct reading of the current charter. But the WG, 
in Vancouver and afterwards on the mailing list, is going to decide on a 
charter update, which may (or may not) change this.

Regards,   Martin.

---

From: James M Snell <[email-masked]>
Date: Mon, 30 Jul 2012 13:40:42 -0700

In all honesty, the existing MIME Media Type system could stand for a bit
of an update [1]... Such changes, however, are certainly well beyond the
scope of the missing to produce an updated HTTP with identical semantics to
1.1. Would definitely be interested in exploring the possibilities of what
could be done here tho.

- James

[1]
http://chmod777self.blogspot.com/2012/04/even-more-on-future-of-mime-media-types.html

On Fri, Jul 27, 2012 at 11:39 PM, Larry Masinter <[email-masked]> wrote:

> "sniffing" in HTTP/2.0. If sniffing is justified for compatibility with
> deployed servers, could we eliminate sniffing for 2.0 sites?
>
> It would improve reliability, security, and even performance. Yes, popular
> browsers would have to agree not to sniff sites running 2.0, so that sites
> wanting 2:0 benefits will fix their configuration.
>
> *From: *Mark Nottingham <[email-masked]>*
> To: *Amos Jeffries <[email-masked]>*
> Cc: *"[email-masked]" <[email-masked]>*
> Sent: *Fri, Jul 27, 2012 06:16:31 GMT+00:00
> *
> Subject: *Re: Straw-man for our next charter
>
>
> >>> How realistic is it to expect the HTTPbis 1.1 draft documents fill
> that role? At least we can guarantee that modifications to adjust them for
> 2.0 specifics will not loose or add any features unintentionally that could
> affect HTTP/1.1 compatibility.
> > concern 1) is the feature parity between the HTTP/1 drafts and any other
> document that gets picked. ie workload to get the new doc completed.
> >
> > Much like what I said in my expression of interest summary. The HTTP/2
> drafts on the tables (own one included) do not come up to scratch for
> HTTP/2 starting points.
> >
> > I know a lot of people have interest in SPDY, but to make that the
> HTTP/2 base doc there are a fair chunk of things which will need pruning
> out - if only because they are new semantics. It is probably not a good
> idea for the WG to start off facing that political battle to ensure its
> semantically seamless to HTTP/1.1. The other documents are bare-bones with
> specific focus on framing improvement over WG drafts part1-2.
>
> > However taking the HTTPbis draft documents and replacing sections of
> them with SPDY mechanisms, frame design, etc as we agree on particulars -
> that has a clear chance of faster success.
>

---

From: Jonathan Ballard <[email-masked]>
Date: Mon, 30 Jul 2012 15:06:48 -0700

Any valid MIME or SMIME under application/<registered-type> also works as
text/<format>+<registered-type>. That possibility does not imply those are
all practical  at the transport layer. It does, however explicitly, suggest
an upgrade or downgrade logical in this context with HTTP/x.y streams.

On Monday, July 30, 2012, James M Snell wrote:

> On Fri, Jul 27, 2012 at 11:39 PM, Larry Masinter <[email-masked]<javascript:_e({}, 'cvml', [email-masked]');>
> > wrote:
>
>> popular browsers would have to agree not to sniff sites running 2.0, so
>> that sites wanting 2:0 benefits will fix their configuration.
>>
>> *From: *Mark Nottingham <[email-masked] <javascript:_e({}, 'cvml',
>> [email-masked]');>>*
>> To: *Amos Jeffries <[email-masked] <javascript:_e({}, 'cvml',
>> [email-masked]');>>*
>> Cc: *"[email-masked] <javascript:_e({}, 'cvml',
>> [email-masked]');>" <[email-masked] <javascript:_e({},
>> 'cvml', [email-masked]');>>*
>> On 27/07/2012, at 4:10 PM, Amos Jeffries <[email-masked]<javascript:_e({}, 'cvml', [email-masked]');>>
>> wrote:
>>
>> >> On 25/07/2012, at 10:02 PM, Amos Jeffries <[email-masked]<javascript:_e({}, 'cvml', [email-masked]');>>
>> wrote:
>> > concern 1) is the feature parity between the HTTP/1 drafts and any
>> other document that gets picked. ie workload to get the new doc completed.
>> >