IETF101: 20 March 2018 HTTP WG Meeting Minutes
Scribe: Bron Gondwana
Active Drafts
BCP56bis: revision of use of HTTP as a substrate
- Mark: good progress - more examples, more review required
- Reviews have been positive - useful outside this group
Bootstrapping Websockets
QUESTION to the room: does anyone have any problems with modifying CONNECT? Nope.
Random access and live content - Craig Pratt (remote)
New standard went out last night - not significantly different to previous,
mostly editorial.
Q: what's left before last call?
* thanks for rattling cages - got feedback.
* expected changes in shift buffers - and that's where they happened
* one question out there: will answer on mailing list, has clear answer
* don't expect to add anything to the draft
- Martin
- suggest: WGLC now
- lots of people have paid attention to it
- Mark: 2 weeks should be fine
* from Jabber:
- Tom Peterson
- see question on mailing list about 416
- answer: while server may internally use circular buffer to represent
shift buffer, shouldn't be a concept of resetting.
- can't internally have a concept of resetting if it's going to be cacheable
- Martin Thompson: great answer, don't need to write it down
Secondary Certificates: Mike
Adopted last time. Have merged it. Exported identifiers (TLS group)
Open issue: handling cases where the client wants to offer a cert because
it expects the server to want it. How we're using frames on streams that
may have already ended. On h2 it's OK, over QUIC doesn't, because it's
already gone.
Mike: don't have advice for detecting key compromise
rotate keys more frequently!
Option: add something to certs that say "don't let me be applied used
in one of these"
ANOTHER POINT: describes a single connection.
- doesn't handle multiple connections, when one has an existing connection
to an origin and another connection claims that same identity. How to
select between them?
- Mike: would be happy to receive some text about it, but generally
you might have multiple connections which are valid for another
server.
Ian - Google
- would also like the idea of opt-in.
- different domains have different risk profiles
More to talk about, not going to WGLC any time soon!
Expect-CT: Emily can't be here.
no comments
Header Common Structure - Mark Nottingham
Martin Thompson
- limits are good
- if you used all of this, then you'd have other problems
?
- always have the option to extend the spec
- Mark: push back on this, if you get more than 256 items, hard error
- point is to have a generic implementation. Don't want to allow override of limits
- Mark: could define structured-headers-2
Roy Fielding
- not sure that this would do any good
- we already have guidance on headers, an nobody follows them already
- who enforces?
- Mark: parser will raise an error only if over 1024
- software then needs to check 'only want 5'
John Lennox
- clearly defaults are great
- ability for specific sub behaviour
- Mark: could just do a non-common header, or define new common-2
Julian Reschke
- maybe would make sense to think about length limits in a different way than
currently.
- maybe just specify whole size of header field?
- Mark: want to think about it, make sure assumption is going to hold
Jeffery Yaskin
- Chrome has a prototype already
- Mark: YAY - shrieked! Patrick insists this is in.
- currently specified as http list syntax - HTTP spec specifies
how to handle multiple headers
Brent/Brand?
- was going to comment in discussion about strings, but:
- URIs? Common data type, should they have separate representation?
- suggest: maximum length of string take URI into account
Cache Digests for HTTP/2 - Kazuho Oku
2 open issues (plus 1 editorial issue not covered today)
Explore on the list
- Hugo
- just to add to the complexity of this, can conceive of servers which are
authoritative for and would like to cache for...
- Patrick: agreement on this, question is whether ORIGIN is correct approach
Question:
+ remove etag/stale support?
+ most URLs the block rendering are long-term cacheable.
+ proposal: remove stale support
- Alessandro Ghedini
- agree that removing would be better
- complication: if HTTP2 stack is separate from cache. If you don't know etag
you would just ignore it anyway
Client Hints
?
- confused about status and direction
- seems like "could include ANYTHING" in there, e.g. geolocation
- Mark: have shied away from adding everything in there - would have
security-privacy considerations
- Second Q: stuff about lifetimes/revocation. "is this how we're going
to do permissions?"
Martin Thompson
- don't like lifetime thing, but consider self to be in the minority.
- got up here to say: changes on slide don't make me happy about security.
- what made him happy: changes to considerations have made him happier.
- opposed to geolocation because don't understand how to control that info.
Eric
- consideration 3 cuts in 2 directions. If you can store cookies and javascript, can already shove this data in a cookie! If you can do that, why do we need the header?
- only difference is for first hit
?
- Preload scanner - well before javascript executes
- taken offline
Not going to WGLC terribly soon
Cookies
No update. Hopefully wind up soonish.
Related Work
Origin-Signed Exchanges: Jeffrey Yasskin, Chromium
Mark: Not considering adopting now, but that might change.
Proposed Work
HTTPtre: Julian Reschke and Roy Fielding
Notion: revise HTTP/1.1 ONE MORE TIME
We have been working in a temporary repo on Github, resurrected the old RFCs,
and published six drafts with minimal editorial updates to reflect status:
- draft-fielding-httpbis-http-messaging-00
- draft-fielding-httpbis-http-semantics-00
- draft-fielding-httpbis-http-conditional-00
- draft-fielding-httpbis-http-range-00
- draft-fielding-httpbis-http-cache-00
- draft-fielding-httpbis-http-auth-00
The question is if the WG wants to adopt these documents with intent to
revise, possibly consolidate, and publish toward full standard status.
Show of hands: 15 people willing to work on this!
- Brad Shorten
- please, fewer documents
- nightmare right now
Either 2 documents or 3 documents.
HUM: "if you want working group to take on draft-fielding-httpbis-*
and produce fewer documents". Strong hums in support, no hums against.
Plan now is to shift over to BIS repo, rename it, and preserve issues list.
Preserving SNI privacy (yep, again)
- Erik
- question about 0-RTT version for *.github.io
- could get cia.github.io in that case.
Patrick: generally sympathetic with work. ALT-SVC might have some things
to say about sni. Not sure if update required.
?
- is your intent that this is widely deployed, or only for specific clients?
- A: think alt-svc and DNS could be a performance win, so expect it to be used
- A: hiding SNI, would be an implementation choice, could cost more
- Q: issue with SNI, can still have your connection replayed
- A: ? cover both cases. If you don't get right cert back, then will have to
make the second round-trip
?
- Host header point: SNI check was used to check if cryptographic context, but
still using Host header to direct to correct backend.
- alt-svc will be used first, then will know what other names can be used.
Martin Thompson
- ACME are looking at using SNI for validating ownership of domains
- this would be a landmine for them.
- what's the relationship between expiration times and RRSET
- A: draft says expiration times must match
Erik
- it's OK if SNI and Host header don't match already.
Authors: are you asking us to adopt these drafts?
- no outstanding issues
- would appreciate adoption
- Martin Thompson
- they're not ready (as a speaker for the NO hum)
- would like to see more discussion on the list
Variants
Adopt?
- Martin Thompson
- relay from Jabber - Tom Peterson
- appears spec denormalises or writes off value of quality indicators
about 10 people have read draft
- Roy Fielding
- wasn't this already asked on list?
- A: Got a bunch of responses. Seen
HUM: in favour of adoption, to be confirmed on the list.
Have parked Key - assumption is that this replaces Key. No objections.
Roy Fielding, as co-author of key: no objection