- Monday, 22 July 2019
- Resource Digests for HTTP - Lucas Pardue
- Using TLS 1.3 with HTTP/2 - David Benjamin
- Proxy-Status - Piotr Sikora
- The Cache HTTP Response Header - Mnot
- Variants - mnot
- BCP56bis - mnot
- Secondary Certificates - Mike Bishop
- Structured Headers - mnot
- Client Hints - Yoav Weiss
- RFC6265bis
- HTTP 2/3 Prioritisation
- Thursday, 25 July 2019
- HTTPSVC record - Eric Nygren
- Priorities
- Core Issues
- https://github.com/httpwg/http-core/issues/218
- https://github.com/httpwg/http-core/issues/215
- https://github.com/httpwg/http-core/issues/212
- https://github.com/httpwg/http-core/issues/196
- https://github.com/httpwg/http-core/issues/196
- https://github.com/httpwg/http-core/issues/180
- https://github.com/httpwg/http-core/issues/169
- https://github.com/httpwg/http-core/issues/34
- Presentation: Braid: Synchronisation for HTTP
Minutes: David Schinazi
Martin Thomson (MT): I like this, few minor comments - will raise as issues
There's already an IANA registry for hash functions
Relationship with SRI? How do they interact?
Roberto Peon: Structured Headers: it would be nice to encode this in binary
Jeffrey Yasskin: The SRI question should go to W3C
Roy Fielding (on jabber) +1 to draft-ietf-httpbis-digest-headers-00 but it might be nice to have a litle more discussion in draft about why the authors think these fields will be useful in future
MT: What principles do we use to define new digest schemes? How do we encode parameterized digests?
Roberto Polli: +1 to MT's comment, parameterizing would solve many issues
MT: Can we just last call this?
Patrick MacManus: Check the list soon after this week
Alessandro Ghedini: Will new status codes need to define new Proxy-Status
Mnot: No, Proxy-Status just means that the status code was generated by the proxy
Chris Lemmons: In the previous proposal, multiple proxies in the chain could have returned different errors
Discussion of caches, which is the next draft in the agenda
Roy F: Why not just use the HTTP 3 digit status code? This tried to refine semantics
Bryan Call: We do this in Apache Traffic Server using a custom header, it allows having it for each hop. Can't this be added to Forwarded?
mnot: Forwarded is a request header. This is a much larger discussion
Roy F (via jabber): I agree when it is new information and not an existing code
MT: What's the relationship between this and Via / CDN-Loop / Cache?
mnot: this is for intermediaries whereas some of the others are request headers. Separating this information out allows robust parsing on clients, and makes it easier to identify proxy-generated responses.
MT: Suggest splitting Proxy-Info and Proxy-Status into separate drafts
Issue 766
Roy F (jabber): I'd really really really prefer this be called Cache-Status (mostly because that aligns it with cache-control and potential future fields that help us isolate semantics specific to caches)
Colin Bendell: We emit these multiple times for beaconing purposes, it would be nice to have a standard so we can send this only once. Also, is there a way to opt in to enable these debug headers?
Mnot: This is currently on a case-by-case basis, negotiating it might be difficult, let's not focus on it for now
Matt Stock: This is clean but it might be very hard to do in practice
Chris Lemmons: Different caches have different interpretations of some of these words so we should define them clearly and make sure existing implementations don't use their current understanding
Alessandro: The more complicated one can be implemented by using the previous stack and converting / splitting up values. This wouldn't be that hard. Problem: this information is mostly consumed by humans so having a bunch more fields might make it hard to read as a human
Chris Lemmons: Apache Traffic Server: someone will implement this
Roberto Peon: Browsers also have a cache, and it's problematic... Should we use HTTP to probe the local cache like we probe remote ones?
Bryan Call: Please add a way to mention that the cache came from RAM
Thomas Peterson: is there not room for allowing for free-form values here for implementations that can't fit in any of these fields?
mnot: need a good extensibility story
mnot: next step: refactor
Not much progress here, waiting for implementations
How do variants work with cookies? That would open up use cases
Colin Bendell: We have an internal implementation and it works well
This used to be blocked on core
Going over issues list
Roy Fielding (jabber): Those all sound like core issues to me
mnot: disagrees for 840 and 774
Chris Lemmons: Users forget that stale exists, having more visibility is going to increase the quality of implementations
Roy F: shrug
Kyle Nekritz: We have a partial implementation
MT: Do not ship this before we have interoperable implementations
Nick Sullivan: Cloudflare has a server implementation, we would like clients to test it
Going over recent changes
MT: can we confirm that this is not specific to the C programming language?
Roy Fielding (jabber): do we have anyone who need float (other than int/1000)?
mnot: problem is existing headers
Roberto Peon: floats give you more precision, if we want to make the tradeoff we should change the name. We may not have widespread use of floats because of how expensive they are to serialize as strings, would be nice to fix that
Chris Lemmons: Suggest fixed-point as name
MT: suggests decimal, then can be stored as an integer
Chris Lemon: Changing the storage will change the bounds, could break people's expectations
Roy Fielding (jabber): +1 fixed-point
MT: we have 10/15 digits on integers, put half on each side of the dot
Chris Lemmons: +1
Roberto Peon: if you allow it, this will increase size over the wire. If this is rare it would be nice to disallow and fall back to ASCII headers
Roy Fielding (jabber): +1 to just sending utf-8 for structured headers
Kazuho Oku: we should do this
Roberto Peon: How do you encode a dict containing an empty dict?
mnot: not the issue here
Julian Reschke (jabber): it is this issue, in that it would resolve it
Roberto Peon: mnot is right, this is not a problem
mnot: this is a footgun, would like to close without action
Kazuho: weak preference, do not add URIs
MT: agree, this is hard to specify correctly
Roy Fielding (jabber): so, we can't have a URI type because a non-standards org has an opinion about which spec to reference? >(
Chris Lemmons: we're just going to encode as utf-8 and might get it wrong
Julian Reschke (jabber): the interop argument actually makes me think we should add this, because it would actually help the consumers, because we would define how it works
mnot: browsers already have a URI parser and won't want to add a new one
Roy: I don't care what the recipient does with the string -- I just want the sender to tell me it is a reference to a URI
Julian Reschke: +1
Matt Stock: this is too complex
Ryan Sleevi: Support punting this issue. The goal here would be to define error processing model and that yak shaving has been going on for a decade and we're not there yet
Roberto Peon: Advantage of structured headers is how we encode things on the wire, and how we represent to the user. Let's talk about this separately
Roy Fielding: then why have any strong typing?
Tommy Pauly: organizing hum, do you want to:
- we should leave this out of the doc (humm in room)
- we should add a strong definition to the doc (no hums)
- we should keep discussing (no hums)
mnot: inferring properties based on prefixes is problematic
Chris Lemmons: if there's a convention someone is going to write software assuming that
MT: we're defining the set of rules for Client Hints, should we force Sec- as a prefix?
Yoav: a prefix will make implementations easier
no objections in room
MT:answer depends on which client hint and how often it changes. Thanks for doing the privacy considerations work, we're almost there
Ryan Sleevi: There were a lot of concerns when developing web crypto API, topic was about accidental leaking of information. This threat is not from a malicious actor but accidental. A Sec-CH prefix may help intermediaries to explicitly not log this information
MT: +1. These are defined for consumption by CDNs so these CDNs might want to log this since it'll impact their behavior
Topic: HTTPSVC + Client Hints
This will be discussed on Thursday
This draft was skipped
Roberto Peon: what matters is what implementations do, not the spec. So h2 priorities failed, let's move on. Need priorities
Kazuho: We should remove priorities from h3
Mike Bishop: multiplexing without priorities is a half-shipped feature
MT: we need prioritization but not signaling of priorities
Minutes: Craig Taylor
https://tools.ietf.org/html/draft-nygren-httpbis-httpssvc-01
Presentation notes (not included in the text): esni may benefit from becoming a seperate draft, right now it's included
mnot: this is not the first time this has come up, and this is already multiple iterations.
Eric: esni is the main push for bringing this work forward now
Ben Shwartz: Points out this draft is intended to be used 'unauthenticated'
Tommy Pauly (individual): Definitely interested in this work and moving it fwd.
Martin Thompson: Enthusiastic about something that gives a less clunky esni record that has the support of the DNS community
RoyF: My understanding of ESNI is limited but I believe it also relies on an additional DNS request to obtain the key for ESNI. Is there a way to piggyback this service information on top of that response instead of making two additional DNS requests?
response in room was that this new request supplants the existing ESNI request
Mike Bishop: The interest for this needs to come from this room, even if httpbis does not complete the work
Eric Nygren: Largely agrees, although other areas to fill out details
Roberto Peon: can anyone fill
Yoav Weiss: Exciting to see the negotiation moving to the DNS layer, considered for client hints, concern about some bloat in the records.
Martin T: If you want some bootstrapping you have to pay some price. In terms of DoH it's only a modest impact, ultimately valuable.
mnot (individual): Sees as generic mechanism that relates to altsvc, so http work
BenS: MAny in this room want this to bootstrap quick, so more relates to this room
Roy Fielding (via jabber): This finally makes srv worth implementing for HTTP
Ben Schartz: Order of submission of requests implies some priority
Roberto: Priority is difficult, and will always be suboptimal, h2 complex -deps+weight+inorder, rich but complex, poor interop, poor implementation, externally implementad semantic schemes exist.
Retaining this increases complexity and doesn't offer 'value' for h3. Personal preference h2 priorities deprecated and replaced with http priorities that makes sense for h2 and h3.
mt: Move to the null state so that we can move to the happy state
we are at the null state already
mnot: ...are you saying that your browser will stop emitting priorities?
mt: ...not discussed internally, but personal opinion is that's the way forward with experimentation required.
Mike Bishop: In the side meeting it was discussed that extension may allow multiple schemes, concern about negotiation of multiple schemes however an extension that allows disable or support may be the best initial state with h3 default state being not_supported.
Roy Fielding: I think that if we can agree that priority can be communicated in a header field for request and response, rather than framing options or whatever, then we can take this whole discussion off of the critical path for QUIC because the priority scheme can be defined as part of that communication regardless of HTTP version.
Patrick McManus: h2 scheme is too general, too much inconsistency and no-one wants to implement.
Patrick looking for group to work toward consensus on a minimal scheme.
Yoav: Request ordering isn't always reliable (cited bug in chrome) Client/Server mismatch is a thing, even good implementation s are not perfect. Support of multiple more simple schemes.
mnot: Big question is what to report to quic for h3
Yoav: Extension mechanism that allows extension, but ship without h2-prio
Alassandro Ghedini: h2-prio are flawed but do provide some value, wary about doing nothing at all. Very open to other schemes.
Kazuho Oku: Fine for browsers to stop sending frames as servers can use other schemes to compensate this behaviour. Clients can send headers of simple table straight away and a translation table can map to h2 or a new h3 scheme.
Alan frindell: Agree h2-pio is broken and not to copy fwd, but not to 'let them go'. Extension for enablement supported. Removing client sent scheme is a worry, and removing from h3 critical path, concern that it will complete. FB only use client side schemes today.
Ian Swett: Support removing h2-prio. Also looking at spending dev time on this... Suspects that something very similar to Kazuho's will end up being used. Slight pref for binary encoding over headers
Lucas Pardue: Uploaded example draft of removing priorities.
Roberto Peon: Header priorities warn, lots of 'issues' (caching, range etc.) However worth solving, and with compression etc, it's going to end up quite efficient.
mt: Likes the designs presented, including the end to end bi-directional nature. Thinks that a transitional approach is useful.
Brad L: missed
mnot (chair): can't deprecate priorities today at this meeting
mt: ...were not asking for adoption 15m after draft was published
Alan Frindell: As a supporter of h2-prio - Still ok for h3 to have no h2-prio, but strong pref for something such as a translatable method.
mnot: Concern over time frames
(chairs): A design team?
Roberto: Plea for low barrier to entry, and welcomes experimentation from Ian...
mt: Can't commit to experimentation in these time frames.
Design Team Volunteers: Ian Swett (lead): Alan Frindell, Kazuho Oku, Craig Taylor, Leif Hedstrom, Roberto Peon, Lucas Pardue, Colin Bendell, Roy Fielding
mt: What other things might cause 403?
seth: 403 often used for resources that should never be exposed so not related to the user
mnot: Discussed and agreed to change
Action: Closed with no action
Roy: Roy has teste since raising and it seems all implementations work
Jeffrey Yaskin: Suggests editorial change to include alternate example
Action: General notice to the group to review the PR
mt: We're going to need some text
Mike Bishop: unsure why we haven't already brought some of 2118 into core semantics
RoyF: +1
mt: Caution - 2818 is old so there is a hazard and the refresh of the language means this is more work than might be expected.
mnot: Suggests a group effort to asses the work
Ryan Sleevi: 2818 needs to "go away": Core parts of 2818 should be included into core semantic, other parts obsolete
Roy: "the https URI scheme semantics are already in 7230"
Roy: I think I understand what to include for establishing authority and can probably make an attempt at obsoleting the rest of 2818; assign to me?
Action: Assign to Roy
No comments
Action: Closed as out of scope
RoyF: ...should we say all URIs?
mnot: Not against that
Roberto: Do we mean the enoded form?
(Roy,mnot): Yes
mt: No difference between either form
Roberto: nod
Action: Proposal accepted
Roy: Duplicate?
mnot: Similar but different
mnot: Suggested close with minor editorial change proposed in issue
Action: Closed
Braid team will be publishing drafts and looking to speak to CDNs/implementors
Alan Frindell: May be work to help with their messaging issues; provide details after meeting
Ben Schwartz: missed this
mt: Thinks this is more than existing messaging methods, and semantics need to move into the protocol
Neil Jenkins: Thoughts on individual documents and collections of documents
Roberto Peon: Interesting problem, highlights balance of trust in getting some clients to make the transformation 'correctly'.