HTTP Working Group Materials

HTTP WG May 2020 Interim Meeting Blue Sheets

Session I

Scribes: Robin Marx, Martin Thomson

Priorities

LP: Main points we’d like feedback on:

MT: are we assuming we need reprioritization? I thought that was in contention

LP: don’t have slides for this, but good point. Should discuss that during the meeting. Would help prevent the need for a frame though.

Ian: Chrome’s behaviour today doesn’t violate normative text in H3 at this time: reordering makes handling of frame-before-header necessary anyway.

Ian: to MT: design team feels reprioritization is important. Already used + there are other use cases that are compelling. Would prefer not to re-visit that decision and keep it in-scope.

MT: just because people are doing it, doesn’t mean it’s good. Not seeing evidence that this is necessary. Is lots of complexity involved in managing two things that aren’t synced. Want to assess it’s really needed (we also “needed” dependency trees, look where that got us)

MT: would like to see: evidence this has material improvement for some class of application + that servers would be willing to implement it (not just Google servers, but more in general) + that it works when a random person implements it

LP: outcome of that decision will impact this headers vs frames debate heavily. Don’t have answer to usefulness for reprioritization. From implementation experience: seems easy enough to parse and adhere to re-prioritization signal, though we don’t do that yet.

Kazuho: we have implemented PRIORITY_UPDATE: bit of a pain to buffer this when reordering happens (though that happens in H2 as well). Not more complicated than H2 and other aspects are simpler than H2, so overall much simpler than H2.

LP: let’s continue with slides and keep this in mind for later

MT: how do you account for resource allocation here? Layering issues: in terms of knowing if a particular stream is allowed or not and Push IDs etc. Is that considered in PR 1167?

LP: Was planning to do that, are some TODOs/early text around that (especially around Push, also update for stream beyond max FC limits). In my experience: no layering violations, as application is in control of limits it asks transport lib to manage on its behalf.

MT: concern was about case where you have a stream budget you expect the transport to manage, but have no idea where it is with that. Then if you get a PRIORITY_UPDATE, you need to cross to the transport and see what the state is, so = layer violation.

LP: based on old PRIORITY frame, so I’d say layering violation was always there.

Tommy: (as individual) shouldn’t assume relationship between app and transport is so directly managed wrt stream limits (e.g., app sets rough allowed “window”)

LP: maybe that’s some general feedback to give to the H3 document beyond priorities, will take that into account.

LP: Which option for having different frame types across priority drafts? Option 1 = tie to H3, Option 2 = presented in presentation (separate weird frame types, later settle on the final ones)

Jabber: use a Transport Parameter to indicate which priority scheme is used?

LP: Long term issue, again a possible layering violation though…

Ian: Option 2 is probably the right option

MT: Upside: implementations would be more tolerant of random junk if we send it. So option 2 is better for that too.

MT: wrt diagramming issue: is an editorial issue

LP: have a slide for that! Options: a) use ascii for H2 and new format for H3 b) pick one c) define only payload d) Other suggestion

Mark: probably best taken to the list, risk of bikeshedding

No takers on the issue about default priority on Push (#1056)

Client Certs

mnot: are there any questions that might inform the decision about whether this might be adopted;

ekr: if the people who want this are willing to deal with the fanciness of the potential solutions to this problem, the answer might be yes; if they are not, then the answer might have to be no

brian: maybe yes, but want a sense of what others think

mnot: we should probably talk about this on the list more

brian: we seem to be in a deadlock currently

mnot: chairs should talk

Colm Divilly / User Defined Resource Error HTTP Status Code

Martin: how do you distinguish between the different entities? THis externalizes some of the state of the server implementation. How does the client care about this.

Colm: Yes, but this fails safe. (many more words, sorry)

Julian: it is possible to reject the creation of broken resources in the first place?

Colm: not always; these are not always created using HTTP, they might use proprietary interfaces

mnot: agree with Martin about how it is unclear who generates the message (was this user code or infrastructure, which leads to proliferation; this is orthogonal to the core reason for the status code; I might prefer that a header be defined for this

colm: how do you deal with the fact that headers aren’t typically captured

mnot: when you standardize, that does tend to result in things hitting logs

cory b: there is prior art here with 502 (gateway timeout), the same problem applies there, but this doesn’t necessarily strike me as a problem that needs to be solved in HTTP, rather it is something for the infrastructure provider to address; other clouds provide monitoring and logging for this

colm: in summary: preference for a header, is there any appetite for a header

mnot: out of time, but maybe

Session I Blue Sheet

Session II

Scribes: Peter Wu and Justin Richer

Signing HTTP Messages

Annabelle Backman:

EKR: concern about picking parts of the headers and how that can be secured.

Annabelle: there are many use cases with different semantics and applications. Intention is to provide a foundation for applications to build a solution for signing.

EKR: Picking and choosing what you’re signing is weak vs just signing over everything

Roberto Polli: removal of expiration property - thinks it is not a secure choice. Signature is bound to the validity. Properties such as expiry should be included in cleartext with the signature.

Annabelle: expiry is not removed, just not included in the examples in the slides. Expiration is also optional. Will take this conversation to the issue tracker. The reason for breaking it into two separate headers: due to limitations of structured headers, parameters are hard. Multiple signatures are hard to do with structured headers. Please reply to the list for security concerns for separating the two.

Due to running of time, Annabelle will take the rest to the list.

Mark: It’s a new draft, everyone be sure to take a look at it

Secondary Certificates

Mike: Concern about lack of client implementations.

Watson Ladd: Cloudflare is interested in this proposal. Offering secondary certificates for subresources in the page.

Mark: considers parking this draft until there are client implementations. There seems to be server interest, but we really need client support.

Mike: Akamai is interested in using it to allow users of client certificates to step up to H2

Mark: Concern about which certificate to use and when; added complexity

Martin Thomson: thinks it’s worth doing, but it is weighing cost/benefits. There are other things competing for time, QUIC, etc. It’s a bit complicated, not opposed to it, just time.

EKR: wonders about the intended functionality. Browsers don’t want to do client certificates in the first place.

Mike: draft was originally written for client certs. Then there was a draft for server certs, then merged. Latest draft allows separately supporting one or the other.

Martin: complexity about getting the UI right is non-trivial. It’s relatively easy to fix the TLS and HTTP stack, but the rest is more difficult.

Digest Headers by Lucas Pardue

Mark: I can help with some of those issues, contact us (+Julian)

Roberto: We need some historical knowledge to move forward

Watson: Draft indicates protection against buggy compression, doesn’t seem to actually do that as specified

Roberto: content-encoding is property of representation, could be mistaken

Lucas: will take a task to discuss offline and work through scenarios into an issue

Cookies 🍪

Update1: RFC6265bis plods forward slowly; in the fixing small issues stage

Update2: browsers experiment with default behaviors beyond what’s specified in the RFC

Annabelle: Some of these features are tripping up legitimate cross-domain use cases. How much outreach is there to the Identity provider community? How can we keep up?

Mike: Challenge is to maintain the stuff about identity transfer but without the wild-west and its side effects. Main venue seems to be the Privacy CG.

Martin: This is going to be a moving target; what’s the end-point?

Mike: Something like http state tokens proposal for an end state. Suggestions for next steps in Cookie Incrementalism

Mike: calls out for help to move the draft forward. It’s an important issue, but not urgent. If implementations like browsers are consistent, but not documented, that is not ideal.

Mark: Reality is bigger than just browsers

Advisory Content-Length for HTTP by Mark Nottingham

Mark: is standardizing this header field helpful? Should it be in the HTTP Semantics document, or separate?

James Gruessing: think it is helpful, it belongs to the Semantics doc.

Julian Reschke: if it’s in semantics, does it affect the standards level we can achieve?

Mark: it’s really just new syntax for an existing feature

Martin Thomson: thinks it is useful for things like progress bars in browsers and chunked encoding or compression.

Barry Leiba: how long would it take for the Semantics document to get out of the door? Can this proposal be added to it?

Mark: pretty soon, but it can become a separate document if needed.

Mark: thinks there is continued interest?

Session II Blue Sheet

Source on GitHub