HTTP Working Group Materials

HTTP Working Group Minutes- IETF 98

Friday, 31 March 2017

Status

Active Drafts (12 minutes each)

RFC6265bis: Cookies

Mike West: 3 drafts adopted.

Drafts are tested in implementations:

* [Cookie Prefixes](https://tools.ietf.org/html/draft-ietf-httpbis-cookie-prefixes):

* Shipped in Chrome 51 (May, 2016) and Firefox 50 (November, 2016)
* Google see some usage of these new cookies
    * 0.004% of `Set-Cookie` headers Chrome sees are using `__Host-` (seen by 1.08% of users)
    * 0.00001% using `__Secure-` (0.03% of users)

Same-site cookies: Chrome 51. 0.01% of usage.

Expect to update the RFC in April.

Issue list not huge. Issues seen in Chrome seem pretty straightforward.

Jim Roskind: stats in number of users. Number given regarding ‘set-cookies’. Could get numbers on users, but not easy.

Early Hints

Kazuho

Mechanism for the server to notify to client what headers are expected to look like in the final response.

Two changes.

Security considerations about cross-origin information leak. If client doesn’t recognize 1xx response and connects through a forward proxy. Non-issue for HTTPS and for HTTP/2.

Mike Bishop: would apply to client doing pipelining? K: would affect both. Mike Bishop: would apply for pipelining without a forward proxy Roy Fielding: Already a concern as 1xx codes can be extended by anyone. Thus this could happen in other cases also.

When to apply 103 headers. Part of the informational response itself, as well as (speculative) part of final response. RFC 7231: MAY ignore unexpected 1xx responses. Two options: - Leave it a MAY or be explicit Current solution: be explicit to have a well-defined behaviour.

Roy Fielding: Some problem with wording, as it can be interpreted as one do not parse the headers. Will send to mail list..

Patrick: good idea to be explicit.

Patrick: no open issue in github.

Kahuzo: once ‘when to apply’ issue is solve, could move to LC.

Roy: could move to LC anyway.

Martin: tweak this, and ship the draft.

Expect-CT (presentation)

Emily Stark

Expect-CT: response header to allow sites to opt in to Certificate Transparency enforcement and/or reporting

Implementation underway in Chrome.

Blockers from TRANS WG

Richard Barnes: Expectation out of TRANS may be to big. Unlikely to result in an consistent policy.

Emily: Don’t have such strong expectation. Want to have something for shipping in Chrome.

Patrick: issues?

Emily: mostly editorial issues.

Set content-type header when sending reports.

Patrick: how do you see next steps?

Emily: maybe TRANS will settle in the next few weeks. Possibly go to LC in Prague

Martin: don’t put expectation in work of TRANS. Once TRANS done, Emily should tell WG and see how it works.

Emily: implementation for LC?

Patrick: has Julian done a review?

Emily: Commented on an issue.

Roy: uses Cookie syntax, which is bad. Copy any other headers. Will file issue.

Roy: still don’t understand why it is not an option on certificates.

Emily: this is not something to keep forever. Hope to remove this header in a few years, when browser have a direct support for CT.

Roy: don’t think it is a good idea to deploy header fields for a limited time.

Martin: regarding syntax should use header structure draft.

Suboh Iyengar: Maybe adding a header from clients to inform server that they are enforcing CT ?, Will file issue

Julian Reschke: I don’t think expect-ct actually uses cookie syntax

Header Common Structure

Patrick: in fairly early stage. Poul is editing it but has limited time to do it.

Patrick: should discuss about it. Whether this work is valuable?

Martin: raised an issue: what’s the posture regarding repeated parameter names. Issue was closed without discussion.

Mnot: intend to make pull requests on this spec.

Patrick: recuring problem. Show of hands for having read draft: 6 people.

Immutable Responses (presentation)

Patrick: need document to update list of cache-control values. But this document is pretty straightforward.

Proposal: LC ready.

Number of thumb-ups.

Cache Digests for HTTP/2

Kazuho:

Two new issues.

Issue #264 Overhead in cache digest algorithm:

Mike Bishop: don’t know what our key are.

Issue #268 Enabling O(1) removal from digest

Stefan Eissing: are browser interested in this?

Patrick: Good to get feedback on implementation status and who.

Kazuho: server-side in Node.js, client-side service-worker. Should have an apendix on how cache-digest should be encoded as HTTP header.

Patrick: what kind of interest got on this work.

Kazuho: browser vendors wondering on whether doing this. Server vendors seem to be more interested.

Stefan: httpd has support, but has not seen any client.

Mike Bishop: interested in it, but don’t have time to implement this. Blind push can be a waste of bandwidth.

Patrick: seems #268 will be hard to resolve without running code.

mnot: I’ve had a discussion with one browser engineer who says they might be trying to implement in the (somewhat) near future; that’s not a commitment, however. I think the question is whether we wait for a browser implementation, or ship it as experimental and see.

Martin: how much to expect to learn from 1 person implementing this. #268 could be resolve on paper. Two paths: park it, or publish it as an experimental draft.

EKR: agree. Either park it or decided on one algorithm to run an experiment with.

The ORIGIN HTTP/2 Frame

Erik Nygren: changes since last version.

Mnot: parked it. Thing it is ready to unpark.

Mike Bishop: relaxing the DNS portion. HTTP/2 says do check the DNS. Do you intended to update RFC 7540?

EKR: two reasons to check the DNS. Want to know where you’re going. For security reasons.

Erik: security aspect and operational aspect. Not following DNS would change many things.

?: Whole point seems to be coasleasing connections.

Patrick: Looked at implementing it and found another experiment on the code point chosen. Issue with reusing?

Martin: We have holes in the registry, but no problem to pick the next value.

Mike: about checking the DNS. If multiple host names, multiple IPs that don’t overlap. Any of these IPs same server, but different certs. Therefore when using origin, these IPs don’t match.

Patrick: privacy aspect on allowing host to replace the DNS. Origin is not block by secondary certs, but the two go well together.

Nick Sullivan: summarize 3 main benefits

Mike: TLS WG: hum showing interest in ???

Patrick: from implementation side Firefox very interested. At least 4 large servers very interested.

Mike: Additional cert draft requires to check the DNS. If compromised Cert need to convince you to connect on any domain.

Nick Sullivan: secondary certs should also skip DNS.

Kile Nekritz:

Erik: right now, DNS as second factor (maybe weak). If compromised cert, need also to compromise DNS for an effective attack.

EKR: 1st attack factor: compromise CA, can do whatever I want.

Erik: still not convinced that origin frame is safe by itself.

Piotr Sikora: origin could allow to hijack all the trafic.

Mike: If connected to server authoritative for several host names, could use it even if DNS tells otherwise.

Suboh: did the original intent changed?

Patrick: original intent was more complex.

Erik: does seem to have been a change in scope. Probably need a broader security analysis on how coalescing works?

Martin: notion of constraining space and expanding it could be made separate. Concerned by middleboxes on the path that want to use these things. Have full control on where packets end. None options relying on DNS help in these scenarios. Only certs work.

Patrick: never fully worked on security properties of routing.

Nick: secondary certs expand domains, origin frame restricts.

Mike: have ability to connect to a proxy: delegates DNS resolving to the proxy.

Patrick: list discussion for consensus on DNS issue. Will ask document authors to bring those issues on the list.

Random Access and Live Content

Darshak Thakore

Range has limitations. Proposal is sort of a hack, but best one could came to.

Martin: advise not to pick too large numbers. Concerned about overflow while server is parsing.

Patrick: no issues. Need more information from WG?

Darshak: feedback from WG would be good. Will update a few things.

Martin: open issues for those things. Once resolved, ask for LC.

Patrick: reviews: Martin, Hanes?, Mark.

Darshak: marked as experimental. Link from 7233?

Martin: would be more confortable once has been tested on the web. Hit some reseanable number of sites to check on server support. Check that results are not really bad, in which case Proposed Standard would be fine. Otherwise can only publish an experimental doc.

QUIC Working Group Collaboration

25 min - Mike Bishop – [Update on the mapping of HTTP/2 and QUIC]

(https://www.ietf.org/proceedings/98/slides/slides-98-httpbis-quic-00.pdf)

Mike Bishop presenting slides from QUIC WG + QUIC Tutorial.

Settings are unchangeable during the connection

EKR: for changing settings, server need to be able to kill the connection while asking the client to restart.

Mike: harder for the server. Would use GOAWAY in HTTP/2.

EKR: difficult to differentiate close and don’t reconnect vs. close and reconnect.

Martin: Proposal was for a flag, I am done and go away

Mike: Aware of one case where settings are used midstream. However, that need will disapear with ?

Martin: do have AltSvc to push someone somewhere else.

HPack replacements

Krasic’s proposal: Add some additional to HPACK: can reference things in same packets or known as received. More complicated, but enables code-reuse

Mike Bishop proposal (presentation from QUIC WG QPACK).

Design issue: how the selected solution for HPACK in QUIC will impact connections?

Need to decide if frame and SETTINGS registries are common between HTTP/2 and QUIC or not.

Mnot: I think that the overlap is at the HTTP semantic layer; frame types, error codes are below that, and using the same registry is going to cause confusion.

Roy: if there are fields values valid in H2 but not QUIC, then have different registries.

Martin: semantic very similar, but with subtle differences.

Mike: HTTP over QUIC, big section on difference of H2 frames in QUIC.

Ben Kadak: If you are going to have the situation that you have similar things but they are subtle different. Then using differnet code point avoids missinterpretation of those subtle differences.

Stefan Eissing: mic: it’s usedul to have extensions for one or the other without taking care of both all the time

Martin: agree with that.

Julian Reschke: question reminds me of the common field registry for email and http

EKR: don’t want someone defining something for H2 and not being ported to QUIC.

Erik: 2 different WG. New feature would need 2 drafts? Or a single draft would be sufficient?

Gabriel Montenegro: Referencing work around link layers. We had a mental model applied to different use cases. We tried to use the same code point when applicable, but in some cases there where was a requirement to use different code points.

Jim Roskind: question of re-ordering. Reordering very infrequent thing. Chrome: can show how much reordering occurs to you. It is really something that happens. Some routers are multithreaded.

Feedback

10 min - Feng Qian – Cross Layer Interaction of H2 Connection Management

Feng Qian

Presentation of results from research work.

Problem: a large transfer fills the TCP buffer and blocks a smaller file when using HTTP/2.

Proposal: new frame for migrating a response to a new connection. Includes provisions for ensuring correct ordering of response-bytes sent across the different connections.

Roy: how does the server knows that two connections belong to the same client?

Feng: need some identifier for the client, that is added to the protocol.

Jim Roskind: how do you cause the second connection to arrive at the same machine? Problem is with load balancing. In addition common that second connection has other egress port and will be directed to different machine.

Feng: haven’t really considered this.

Piotr Sikora: solution: lowering the TCP buffer, so that the frame can stay in the HTTP server.

Feng: if too small, performance can be affected. Difficult to come with the optimal value for the TCP buffer.

Kazuho: setting TCP buffer to exact size of RTT.

Feng: difficult to predict the network condition changes to set the right value.

Patrick: this is a hard problem, but not impossible. Survey to find what people are doing in the real?

Feng: want to do some measurements on how servers are behaving. Most important thing is the behaviour of the user.

Mike: both Linux and Windows expose info on how much data is needed by TCP to maintain the link saturated. Would be interested to find what sites take advantage of that.

Feng: did some experimentations and found all servers have this problem to different degrees.

Jim Roskind: this is bufferbloat in the server. Should be addressed at the server level, not at the HTTP level.

Benjamin Schwartz: TCP_NOT_SEND_LO_WHAT? option in TCP. It’s recommended in some documentation for implementating HTTP servers.

Piotr Sikora: ???

Kazuho: connection migration has benefits: could migrate one request to a cache.

Source on GitHub