Subject: Reminder: Call for Proposals - HTTP/2.0 and HTTP Authentication

From: Mark Nottingham <[email-masked]>
Date: Fri, 27 Apr 2012 15:28:06 +1000

Just a reminder that we're still accepting proposals for:

1. HTTP/2.0
2. New HTTP authentication schemes

As per our charter <http://datatracker.ietf.org/wg/httpbis/charter/>.

So far, we've received the following proposals applicable to HTTP/2.0:
  <http://trac.tools.ietf.org/wg/httpbis/trac/wiki/Http2Proposals>

But none yet for authentication schemes:
  <http://trac.tools.ietf.org/wg/httpbis/trac/wiki/HttpAuthProposals>

As communicated in Paris, the deadline for proposals is 15 June, 2012. It's fine if your proposal isn't complete, but we do need to have a  good sense of it by then, for discussion.

Regards,

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

---

From: James M Snell <[email-masked]>
Date: Thu, 26 Apr 2012 23:43:01 -0700

Great to see this work getting underway. I don't have any particular
firm proposals from a fundamental HTTP/2.0 messaging and semantics
level, but I do have a few items on my wishlist from an HTTP-based API
developers point of view that I would like to see addressed in 2.0..

Requirements to Consider for HTTP/2.0 from an API Developers Point of View

1. It needs to remain as simple as possible. Right now, when showing
someone how to utilize an API, I can simply type:

  POST /a/uri HTTP/1.1
  Host: example.org
  Content-Type: text/plain

  Hello World

  And give them all the information they need. Whatever the actual
transport ends up being, at some level we have to make sure we don't
lose this kind of "View Source" visibility.

2. Allow the Request-URI to be a Request-IRI so no conversion is
necessary. E.g. it should be possible to do this at the request level
and have it just work...

  POST /a/üri HTTP/2.0
  Host: éxample.org

  For that matter, can we allow extended characters in all the headers
and use UTF-8 as the default encoding.

3. Use ISO-8601/RFC3339 Timestamps for more precise date/time handling

  Date: 2012-12-12T12:12:12Z
  Last-Modified: 2012-12-12T12:12:12.012Z
  Expires: 2012-12-12T12:12:12.123Z
  // or even

  Expires: P2D3H    (using an ISO-8601 Duration)

4. It would be helpful to have a "standard" means of signing requests
and responses. SSL/TLS is good, but it doesn't always meet the
requirement (see OpenSocial Signed Fetch as an example)

5. Batched-Requests keep popping up and implementors keep coming up
with proprietary ways of handling them (e.g. Facebook, Google,
OpenSocial.. and others). The primary reason given is efficiency...
doing more stuff in a single request. It would be helpful for HTTP/2.0
to definitively address this so we don't keep ending up with a bunch
of relatively half-baked vendor specific batching models that attempt
to bundle http message semantics inside message payloads.

6. Please consider incorporating the Mac and Bearer token
authentication mechanisms as standard HTTP authentication schemes.

7. Please consider incorporating the PATCH method into the core set of
HTTP 2.0 Methods

8. Please consider incorporating the Prefer header into the core set
of HTTP 2.0 request headers.

9. The X-HTTP-Method-Override header has emerged as the de facto
standard way of getting around intermediaries that inadvertently block
extension http methods (like PATCH). It would be helpful for HTTP/2.0
to offer some prescriptive solution so that this kind of
Tunneling-through-POST hack isn't necessary any more.

10. Currently within HTTP/1.1 the 202 Accepted response says The
representation returned with this response SHOULD include an
indication of the request's current status and either a pointer to a
status monitor or some estimate of when the user can expect the
request to be fulfilled" but otherwise does not provide a standardized
means of referencing the location of the status monitor or determining
whether the asynchronous operation is complete. A variety of means
have been proposed but it would be helpful for 2.0 to flesh this out
in detail. For instance, a Location header in the 202 response can be
used to reference the status monitor; when a user-agent then does a
GET on that URL, a 202 response can indicate that the request is still
being processed. e.g.

// post a long running request //
POST /some/resource HTTP/2.0
Host: example.org

{.. some data to process ..}

// get back an asynchronous response //
HTTP/2.0 202 Accepted
Location: http://.../status-monitor/1
Retry-After: 120

// check the status 120 seconds later //
GET /status-monitor/1 HTTP/2.0
Host: ...

// response is not yet completed
HTTP/2.0 202 Accepted
Location: http://.../status-monitor/1
Retry-After: 120

// check the status 120 seconds later //
GET /status-monitor/1 HTTP/2.0
Host: ...

// processing is complete, server returns a redirect to the actual resource
HTTP/2.0 302 Found
Location: http://.../the/resource

The use of the 2xx status code rather than 3xx avoids the potential
for an endless redirect loop with user-agents that blinding follow
unknown/unrecognized redirection codes. Also, if you consider the
nature of the status monitor, a notice to the client that the
processing is not yet complete is a valid success response.

Specifying this kind of behavior out in detail will allow asynchronous
operations to be deployed in an interoperable and reliable way.

In any case, that's all I have for now. I'm sure other ideas will pop
into mind later on but hopefully these are enough to chew on for a
bit.

- James

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 27 Apr 2012 16:54:47 +1000

Hi James,

Thanks. Some quick responses below.

> lose this kind of "View Source" visibility.

I think there's a growing feeling that this is Nice To Have, but not required. See recent discussion.

> necessary. E.g. it should be possible to do this at the request level

That would be interesting, but the effects of such a change would have to be carefully considered.

> and use UTF-8 as the default encoding.

It's not clear that we're going to be able to do that, because it requires knowledge of the headers to translate between the different encodings. The benefit would be relatively small for a LOT of work.

>  Expires: P2D3H    (using an ISO-8601 Duration)

The encoding of such values has already been discussed quite a bit, but the focus so far has been on efficiency.

> requirement (see OpenSocial Signed Fetch as an example)

That's an interesting topic. So far, our discussions on security have been about TLS vs no TLS, but I'd welcome discussion that had a finer gradation.

Personally, I find signing responses quite interesting, as it would allow clients to assure that they haven't been tampered with (ads inserted, etc.), while giving intermediaries (e.g., virus-sniffing firewalls, caches) some visibility.

> to bundle http message semantics inside message payloads.

I think that's addressed by multiplexing, which is part of most proposals we've discussed so far.

> authentication mechanisms as standard HTTP authentication schemes.

We need proposals to do this.

> 7. Please consider incorporating the PATCH method into the core set of

It already is... see the registry.

> of HTTP 2.0 request headers.

It's on a separate track. Note our charter; we're barred from introducing new features, in most cases.

> Tunneling-through-POST hack isn't necessary any more.

So that misguided implementers can break that as well? Perhaps then we'll have an X-X-I-Really-Mean-It flag?

> operations to be deployed in an interoperable and reliable way.

That's out of scope for this work, I think.

Cheers,

---

From: James M Snell <[email-masked]>
Date: Fri, 27 Apr 2012 00:32:07 -0700

> I think there's a growing feeling that this is Nice To Have, but not required. See recent discussion.

So long as the basic operations can still be semantically represented
this way in order to describe the overall structure of the request,
it's fine if it doesn't look this way actually on the wire.

> That would be interesting, but the effects of such a change would have to be carefully considered.

Agreed. It certainly could be quite a disruptive change actually and
carries a number of potential additional security risks, for sure.

> It's not clear that we're going to be able to do that, because it requires knowledge of the headers to translate between the different encodings. The benefit would be relatively small for a LOT of…

It may be because it's after midnight and I really should be getting
some sleep, but i don't quite follow what you're saying about
requiring knowledge of the headers to translate between the different
encodings.

> The encoding of such values has already been discussed quite a bit, but the focus so far has been on efficiency.

So long as it makes it in there "eventually", I'm happy :-)

> Personally, I find signing responses quite interesting, as it would allow clients to assure that they haven't been tampered with (ads inserted, etc.), while giving intermediaries (e.g., virus-sniff…

Precisely. Fortunately, this is one of those types of things that can
be worked up independently of the rest of the more immediate issues of
efficiency (although generating a signature over the request certainly
can impact the efficiency of the request... Just thinking off the top
of my head, assuming we ultimately ended up with something based on
SPDY, we could possibly achieve this by introducing a new SIGNATURE
frame following the final DATA frame (or last SYN_REPLY/SYN_STREAM if
there is no payload). Not sure if that's workable or not, but it's
something that should at least be explored.

> I think that's addressed by multiplexing, which is part of most proposals we've discussed so far.

I certainly hope so... I also hope that it's straightforward enough of
a mechanism to utilize to convince folks that batching of requests
truly isn't necessary... Right now, there are just way too many people
who think it's a perfectly fine thing to stick method names and http
headers and etags all bundled up into a JSON document in a kind of
bastardized pseudo-http-within-http-because-the-real-http-is-kinda-sorta-not-adequate-in-some-way
model.

> So that misguided implementers can break that as well? Perhaps then we'll have an X-X-I-Really-Mean-It flag?

Sadly I share the same concern with regards to the whole multiplexing
and batching discussion. Regardless of that, it would be helpful to at
least explore what, if anything, can be done to make it easier to
bootstrap the use of new methods.

> That's out of scope for this work, I think.

Very well. Perhaps it would be worthwhile for me to write something up
on this independently then.

---

From: Willy Tarreau <[email-masked]>
Date: Fri, 27 Apr 2012 09:38:02 +0200

> requiring knowledge of the headers to translate between the different

Some header fields might very well contain some data that are not to
be considered as text and will not be utf-8 encoded. So it might be a
real pain to know what must be transcoded and what must not be. This
is the reason why in websocket we have implemented a frame type from
the beginning (binary/text).

Regards,
Willy

---

From: Mark Nottingham <[email-masked]>
Date: Fri, 27 Apr 2012 17:39:21 +1000

> requiring knowledge of the headers to translate between the different

Right now, it's possible to encode non-Latin-1 characters into headers using an encoding, like that described in RFC5987.

However, that isn't a blanket encoding; i.e. the header definition has to specify its use. Generic software can't just look at headers and say "look, that's internationalised"; it has to know the header's specific syntax to lift it up to UTF-8 (for example).

> on this independently then.

Please do, I think that would be interesting.

Cheers,

---

From: Nicolas Mailhot <[email-masked]>
Date: Fri, 27 Apr 2012 08:40:23 +0000 (UTC)

> 3. Use ISO-8601/RFC3339 Timestamps for more precise date/time handling

Hear, hear

I don't expect browsers of http servers to care a lot about those, but it would
considerably simplify things for all the rest of the ecosystem if http/2.0
switched from the encoding and timestamp standards that existed decades ago to
the ones that have evolved since (I send yesterday  an RFE to one of our tool
suppliers, enumerating problems we spent months of collecting, and 3/4th of them
were related to naïve encoding or timestamp handling). Please take advantage of
http/2.0 to streamline all of this and dump the baroque solutions that existed
before i18n problems forced the creation of better standards.

Just make text UTF-8 par default, dates ISO-8601 (and UTC!) and add a prefix for
binary headers. This way apps and scripts could finally use common date/text
libraries instead of having to pass everything through http-specific filters
(and have things break whenever the filter if forgotten or the custom filtering
code has bugs)

Best regards

-- 
Nicolas Mailhot

---

From: Nicolas Mailhot <[email-masked]>
Date: Fri, 27 Apr 2012 09:16:00 +0000 (UTC)

Hi,

Would it be possible to publish a list of specific questions and have each
proposal submitter answer how its proposal answers each of them? Just to make
sure no use-case falls through the cracks? Sure one can read each proposal and
guess the answers, but I think proposal submitters are the best to answer how
their proposal could be used. And this way one won't have to fish list archives
for answers to common questions.

I'd especially like an answer to the following:

1. Can the proposal permit secure http/2.0 communication without letting malware
punch random protocols through firewalls using the http/2.0 secure port?

2. How can intermediary network nodes request (re-)authentication on secure
networks when client credentials expire?

3. How can they communicate authentication location to the client (or is it
implied and how)? Does this mechanism work for dumb (not-browser) web clients?

4. How could other intermediary messaging be handled?

5. Is the proposed protocol feature-complete or does it require an http/1.1
downgrade to handle some existing http use-cases (esp. proxy ones)?

6. Is the http/2.0 namespace a superset of the http/1.1 namespace? Are error
codes specific to the protocol version used or should it be assumed they'd apply
the same if the protocol was up/down graded?

7. How will the proposal make writing tools that process HTTP headers and logs
simpler? Does it reduce HTTP reliance on conventions not commonly used in
mainstream application writing?

8. Does it add specific logging constrains that didn't exist in http/1.1?

9. How will the proposal improve network efficiency?

Best regards,

-- 
Nicolas Mailhot

---

From: Willy Tarreau <[email-masked]>
Date: Fri, 27 Apr 2012 11:29:08 +0200

Hi Nicolas,

> for answers to common questions.

I'm not sure this will help make great progress in the short term (only 1.5
month is left for proposals, and working on them takes a *lot* of time).

> punch random protocols through firewalls using the http/2.0 secure port?

You'll never ever be able to guarantee this. Malware can use whatever
encapsulation they need. Some communicate via text messages on twitter.
The rule is simple : if at least one bit can leave a place, it is possible
to communicate with the outside world. So this is totally out of the scope
of future designs.

> networks when client credentials expire?

Unless I miss your point, that's what the 401 is about, no ?

> 4. How could other intermediary messaging be handled?

I'm not sure I get these points.

> downgrade to handle some existing http use-cases (esp. proxy ones)?

It needs to be able to completely replace it otherwise it will mean much
more work for many implementers, leading to many more bugs and interop
issues.

> the same if the protocol was up/down graded?

Since we have to be able to be able to transport 1.1 over 2.0 with "reasonable
fidelity", I think we should at least be able to adopt the existing namespace
whatever it's encoded.

> mainstream application writing?

This depends on proposals but it seems like everyone agrees that right now
the syntax is too lax and that we must make it a bit more strict.

> 8. Does it add specific logging constrains that didn't exist in http/1.1?

Logging is out of the scope of HTTP in my opinion as it's an implementation
choice.

> 9. How will the proposal improve network efficiency?

At least by reducing message sizes, packet counts and connection counts.

Regards,
Willy

---

From: <[email-masked]>
Date: Fri, 27 Apr 2012 11:54:06 +0200

Hi,

RFC 3310 is informational but used in mobile networks. I think it is worth to consider the interest of defining this mechanism as "standard" HTTP authentication scheme. What should be the process?

In the same line, I have a draft on adaption of RFC3310 for 2G AKA (see. http://tools.ietf.org/id/draft-morand-http-digest-2g-aka-02.txt). I would propose to add it to the list of new potential authentication schemes but only if RFC 3310 is part of the same list. Otherwise, it could be only informal.

Regards,

Lionel 

-----Message d'origine-----
De : Mark Nottingham [mailto:[email-masked]] 
Envoyé : vendredi 27 avril 2012 07:28
À : HTTP Working Group
Objet : Reminder: Call for Proposals - HTTP/2.0 and HTTP Authentication

1. HTTP/2.0

Regards,

---

From: Nicolas Mailhot <[email-masked]>
Date: Fri, 27 Apr 2012 10:44:38 +0000 (UTC)

Willy Tarreau <w <at> 1wt.eu> writes:

Hi Willy

> > proposal submitter answer how its proposal answers each of them? 
> 

Maybe, but in the long term, this kind of question will need answering anyway,
so it's dangerous to postpone them IMHO. That adds the risk of painful later
reworks if something is missed in the initial phases.

> > 1. Can the proposal permit secure http/2.0 communication without letting
> > malware punch random protocols through firewalls using the http/2.0 secure
> > port?

> You'll never ever be able to guarantee this. 

Right but there is a difference between allowing some leaking, and being so lax
one can push full vpn/remote desktops through the https port. If one of the
proposals improve this situation that would be a definite plus.

> Unless I miss your point, that's what the 401 is about, no ?

The point is proxy/gateway auth as before. Especially for proposals that push
for full TLS encryption, when it is the most broken case right now.

Right now most browsers propose opening an http connection to a specific URL to
trigger portal auth. That's broken by design (http and https are different
namespaces, and different URIs may be subjected to different filtering)
and instead of fixing this some of the proposals make the situation
worse as far as I can tell.

> > 3. How can they communicate authentication location to the client 

Again, how can proxies and gateways communicate with the web client. Or to put
it otherwise: is the proposal compatible with Enterprise network security or
does it require changes elsewhere that may or may not happen while Enterprise
users get cut from the new http/2 web?

For example if a proposal requires a new proxy protocol to be proxified the
proxy protocol changes should be submitted alongside it, not in some
hypothetical future.

> more work for many implementers, leading to many more bugs and interop

I agree but I'm sure some answers to 2. will be 'open an url to
http://youre-on-the-internet.com/ in http 1.1'. And there may be other cases
I'm not aware of.

> Logging is out of the scope of HTTP in my opinion 

If you add multiplexing, logging (and log processing) needs reworking. How much
depends on how the proposed multiplexing works. Implementers (both server,
intermediary and client side) need to be informed of the new elements that need
logging now

> At least by reducing message sizes, packet counts and connection counts.

This is the only question reasonably answered in the proposals though not two
proposals address it the same way

Regards,

-- 
Nicolas Mailhot

---

From: James M Snell <[email-masked]>
Date: Fri, 27 Apr 2012 18:50:54 -0700

> However, that isn't a blanket encoding; i.e. the header definition has to specify its use. Generic software can't just look at headers and say "look, that's internationalised"; it has to know the h…

Right, but could we not "simply" do what WebSockets has done and
define distinct binary and text data frames in which the text frame
always assumes UTF-8? With such an approach, we would not need to
worry about things like RFC5987 or determining whether the header is
defined as being i18n'able.

- James

---

From: <[email-masked]>
Date: Mon, 30 Apr 2012 19:02:28 +0200

Any feedback?

Lionel

-----Message d'origine-----
De : MORAND Lionel RD-CORE-ISS 
Envoyé : vendredi 27 avril 2012 11:54
À : 'Mark Nottingham'; 'HTTP Working Group'
Objet : RE: Reminder: Call for Proposals - HTTP Authentication

Hi,

Regards,

Lionel 

-----Message d'origine-----

1. HTTP/2.0

Regards,

---

From: Peter Lepeska <[email-masked]>
Date: Mon, 30 Apr 2012 17:22:22 -0400

Hi Mark,

Earlier this group discussed the idea of a "trusted proxy". Does that fall
under the HTTP/2.0 category?

I may have some cycles for this.

Thanks,

Peter

On Fri, Apr 27, 2012 at 1:28 AM, Mark Nottingham <[email-masked]> wrote:

> As communicated in Paris, the deadline for proposals is 15 June, 2012.
> It's fine if your proposal isn't complete, but we do need to have a  good
> sense of it by then, for discussion.
>
> Regards,
>
> --

---

From: William Chan (陈智昌) <[email-masked]>
Date: Mon, 30 Apr 2012 14:43:00 -0700

FYI, we (google spdy team) have been discussing a "trusted proxy"
internally and I think Roberto's got a draft in the works.

---

From: Peter Lepeska <[email-masked]>
Date: Mon, 30 Apr 2012 17:45:08 -0400

Perfect then I'll sit tight.

Thanks,

Peter

On Mon, Apr 30, 2012 at 5:43 PM, William Chan (陈智昌)
<[email-masked]>wrote:

> On Mon, Apr 30, 2012 at 2:22 PM, Peter Lepeska <[email-masked]>wrote:
>
>> Hi Mark,
>>
>> Earlier this group discussed the idea of a "trusted proxy". Does that
>> fall under the HTTP/2.0 category?
>>

---

From: William Chan (陈智昌) <[email-masked]>
Date: Mon, 30 Apr 2012 14:57:54 -0700

On the contrary, I think it's great to have multiple proposals. If you have
your own vision for how this should work, please send it out! :) My
statement was simply an FYI, not a "back off, we've got this!"

On Mon, Apr 30, 2012 at 2:45 PM, Peter Lepeska <[email-masked]> wrote:

> On Mon, Apr 30, 2012 at 5:43 PM, William Chan (陈智昌) <[email-masked]
> > wrote:
>

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 1 May 2012 10:57:10 +1000

Hi Lionel,

Do you know of any use outside of a mobile context? If there's interest, we can certainly look at it, but if it's relegated to just that market (whether or technical or social reasons), I don't think this would necessarily be the right place to advance it to a standard (speaking just for me).

Cheers,