HTTP Working Group Materials

HTTP Working Group Minutes - IETF105 Montreal

Monday, 22 July 2019
Thursday, 25 July 2019

Monday, 22 July 2019

Minutes: David Schinazi

Resource Digests for HTTP - Lucas Pardue

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

Using TLS 1.3 with HTTP/2 - David Benjamin

MT: Can we just last call this?

Patrick MacManus: Check the list soon after this week

Proxy-Status - Piotr Sikora

Issue 808

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

Issue 821

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

The Cache HTTP Response Header - Mnot

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

Variants - mnot

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

BCP56bis - mnot

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

Secondary Certificates - Mike Bishop

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

Structured Headers - mnot

Going over recent changes

Issue 848

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

Issue 844

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

Issue 842

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

Issue 801

Roberto Peon: mnot is right, this is not a problem

Issue 782

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)

Client Hints - Yoav Weiss

Issue: Sec-CH prefix

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

Issue: structured headers

no objections in room

Issue: active vs passive fingerprinting

MT:answer depends on which client hint and how often it changes. Thanks for doing the privacy considerations work, we’re almost there

Issue: client hints could end up in logs

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

RFC6265bis

This draft was skipped

HTTP 2/3 Prioritisation

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

Thursday, 25 July 2019

Minutes: Craig Taylor

HTTPSVC record - Eric Nygren

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

Priorities

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

Core Issues

https://github.com/httpwg/http-core/issues/218

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

https://github.com/httpwg/http-core/issues/215

Action: Closed with no action

https://github.com/httpwg/http-core/issues/212

Roy: Roy has teste since raising and it seems all implementations work

Jeffrey Yaskin: Suggests editorial change to include alternate example

https://github.com/httpwg/http-core/issues/196

Action: General notice to the group to review the PR

https://github.com/httpwg/http-core/issues/196

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

https://github.com/httpwg/http-core/issues/180

No comments

Action: Closed as out of scope

https://github.com/httpwg/http-core/issues/169

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

https://github.com/httpwg/http-core/issues/34

Roy: Duplicate?

mnot: Similar but different

mnot: Suggested close with minor editorial change proposed in issue

Action: Closed

Presentation: Braid: Synchronisation for HTTP

https://braid.news
https://tools.ietf.org/html/draft-toomim-braid-00#section-4

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’.