# httpbis WG minutes IETF-92 Dallas -- Tue afternoon 1300h - [post-wg specs](#post-wg-specs) - [Current extension spec issues](#current-extension-spec-issues) - [alt-svc issue 44 - think we have agreement on it](#alt-svc-issue-44---think-we-have-agreement-on-it) - [alt-svc issue 43 - ALPN Identifiers](#alt-svc-issue-43---alpn-identifiers) - [OppSec issue 33](#oppsec-issue-33) - [tunnel protocol for CONNECT](#tunnel-protocol-for-connect) - [Potential Work](#potential-work) - [http signature](#http-signature) - [HTTP client hints](#http-client-hints) - [key http response header field](#key-http-response-header-field) - [json encoding the http header fields](#json-encoding-the-http-header-fields) - [www-authenticate I-D that uses the JSON HF definition technique](#www-authenticate-i-d-that-uses-the-json-hf-definition-technique) - [451 status code to report legal obstacles](#451-status-code-to-report-legal-obstacles) - [indicating char encoding and lang for http header field parameters](#indicating-char-encoding-and-lang-for-http-header-field-parameters) - [client init'd content encoding](#client-initd-content-encoding) - [2NN Patch Status Code](#2nn-patch-status-code) - [origin cookies and 1st party cookies](#origin-cookies-and-1st-party-cookies) - [encrypted content-encoding for http](#encrypted-content-encoding-for-http) - [Issues against the httpbis docset](#issues-against-the-httpbis-docset) - [H2 (aka HTTP2) deployment advice](#h2-aka-http2-deployment-advice) - [mpeg dash](#mpeg-dash) ## post-wg specs no discussion ## Current extension spec issues ### alt-svc issue 44 - think we have agreement on it pat mcmanus(pm) is fine with it ### alt-svc issue 43 - ALPN Identifiers martin thomson (mt) explains the detailed context ought to document the more broad connotations in the spec/doc mnot: we should clarify that http/1.1 means HTTP/1.1 over TLS mnot: we do have several issues open that aren't controversial -- need editors to update draft(s) and close out the issues pm: ff37 impls this stuff, in beta, so folks can try that ### OppSec issue 33 is open and needs to be incorp'd, then goto WGLC with this for 2 wks mnot: moz impl'g, akamai on server side, other bwsrs? desires to advance this in compnay of alternative svcs ### tunnel protocol for CONNECT has been discusssion, but no open issues, can goto WGLC martin thompson(mt) there is not as much context in the into matterial so see the open pull request. Had priv feedback that they were unhappy with this but webrtc apps will have this header field forced on them mnot: yes, in general can't make new header fields mandatory in http' but apps such as webrtc can do so, thus making that explict is nice/useful Go ahead and put the text in, will issue WGLC ekr: might need some wordsmithing that some traffice analysis of this stuff is possible -- will suggest text ## Potential Work See http wiki page "WatchList" mnot: only want to keep WG open if there's useful work to do. Might be some of these the WG may want to dive into... ### http signature draft-cavege-http-signatures-04 tad early to adopt this? ### HTTP client hints have heard browser folk express interest in this larry masinter(lm): there was work in this area 10 yrs ago -- already extant RFCs that cover much of this territory mnot: agree that the above should be eval'd in that light ekr: relates to client fingerprinting -- we ought to minimize passive fp surface and not worry so much about active so this draft may surface that struggle interest in spec? some yes... pm: not every client is a browser; its not like you require a ietf wg to mint a header -- could experiment actively with it not just hack spec chris bentzel goog: interested in this; if you have tcp proxy this might be useful peter griess FB (pg): interested in this too, eg for mobile website ?: might be useful for DASH mnot: am concerned about privacy concerns tho ### key http response header field is a way to establish a secondary cache key that VARY selects. Vary is coarse, in usual case it is difficult to use to establish a secondary cache key. This spec is way to derive a more fine-grained secondary cache key. might be either do this spec or kill 2ndry cache keys altogether Ilya G likes this; if we adopted client hints -- we'd need this. stuart cheshire (sc): iTunes team would like this mt: concern w/this is the complexity -- trim it and leave open door for enhancing in future sc: will ask them for specific needs mnot: right not is kitchen sink-y (...describes...) part of issues with this is header syntax ### json encoding the http header fields idea here is use json to describe header field, then serialize into header field value, could be a win jr: it also makes internet aka i18n easier phb: in long term we'll move to using json for everything. presently have class of headers for routing etc and a class for content -- would want to teases apart eliot: how does jr view the transition to this working? mnot: if i define a new header, then use this going forward roy fielding: this is not an opportunity to define http/3 jr: trying to address defining new http header fields easier phb: need a header field schema... mnot: ### www-authenticate I-D that uses the JSON HF definition technique mt: would need something more concrete than "just use json". Suggests like two practices for how to use pg: having doc on header definition best practices would be helpful mnot: putting aside the specific proposal -- have a HUM on a doc defining a convention for defining header definition conventions decent hum on interest almost none on harmful a little on don't know mike bishop via jabber: this could encourage data smuggling via headers oiwa: : < something about the www-authn example> mnot: agree that was/is confusing ### 451 status code to report legal obstacles mnot: discussion on list. A few folks think the semantics not well enough sorted out. Would like to discuss now. barry leiba (bl) participant: is ok with what the WG thinks (formerly opposed). What were the args wrt insufficient semantics ? think they are pretty clear paul hoffman (ph): tim puts up examples of folks using this. So, it can be used. It has shown to be sorta useful, but maybe not super useful. mnot: some folks said just use 403 with a response body ph: but that would change semantics of 403 lm: I pushed back on this purpose seems to be political theatre why not be informational? mnot: a use case is if you want to crawl web and get indications of censorship phb: this status code is supplying addttnl info. It isn't law here is the issue itself, but in brings the law into the picture.... jon peterson(jp): could imagine getting a diff page with a 406 wendy seltzer: chilling effects project thinks this useful potentially mnot: we could define header fields that'd be used in conjunction with this status code ?: something about could indicate the proxy or origin blocking access to this content mnot: two status codes perhaps bl: anybody say "no"? (no objection) ### indicating char encoding and lang for http header field parameters this'd be just adopting and finishing the spec. should be close to done "It was a WG spec" jr says -- but recants -- mnot celebrates ### client init'd content encoding another jr spec allows client to use content-encoding on requests server can use accept-encoding in responses mnot asks client implementations -- would u use this? jr: has addressed the issues from last meeting mnot: is an incremental optional addition to http, some folks could use it, makes sense to adopt lm: how's the interact with http header scoping? mnot: have to treat as a hint ### 2NN Patch Status Code mnot: esoteric use case mt mt: I could see how it'd be useful in narrow cases. Could annoy api creators roy: Yuk. ?: we currently do this when running commercial proxy roy: effectively make all requests VARY lm: don't you have to tie it to etag ? mnot: yes, strong etag ?: w/intermediates, will be like 206 (roy later says it won't make all requests vary) ### origin cookies and 1st party cookies mnot: Seems a number of folks are interested, but they are limited given how deployment will happen. couldn't rely on them being there and so limited utility? mt: <...various gnarlyness wrt cookies...> ?: discussing with someone and intend to continue to work on this draft (which one?) mt: in terms of csp, compliant UAs gain a bit of resistance to stuff like CSRF mnot: need to have chat with Mike West and webappsec folk mnot: some interest but need more discussion ### encrypted content-encoding for http mnot: working on this w/MT mt: coupl use cases: webpush, need to push stuff thru intermediary, encrypt doc on server mt: This is just a simple cut down version of tls record layer and some key mgmt mt: there's some impls -- pretty interested in getting this going mt: using jose didn't work in http semantics. eg a msg being processed continuously rather than a single blob mt: no optionality in the format -- simple mt: will engage w/sec folk lm: there's desire afoot to secure http headers and optionally body and so .... ph: why wont CMS w/smime eg smime 3 not work? pls engage smime list mnot: so this spec is an fyi at this point ## Issues against the httpbis docset mnot: eventually take it to full std. once http/2 is done, align with http2, then try full std. Can't see us starting this now, but maybe later this year? jr: no further thoughts ## H2 (aka HTTP2) deployment advice We have a faq on wiki, but info is thin. There is perf increase but to really get in full need to tweak lots of deployment configs. Would be helpful to write down advice. lm: have chatted w/folks this week. 2 aspects: 1. What does it mean to benchmark http on the real internet? How do you measure whether one deployment is better or worse? 2. and then deployment advice for how to attain improvements mnot: w3c webperf wg -- could engage with them on this? lm: lots of folks at IETF who know internet perf too -- will the lower layer folks interface with the webperf wg ? mnot: RUM is interesting because it measures end user perf perspective -- in real world settings -- thus we really ought to engage with them ph: we have benchmarking wg -- would not have this go there -- long time leads. Thinks webperf & rum is beter route Dan Druta: goal-based: what do u want to improve? latency? load? etc. Stakeholder-based: e.g. for web developers, for web masters, for service providers, etc... both dimensions do both. mnot: suggests starting effort on the wiki -- need folks to be willing to do work thinks webperf folks will eventually address it, but would be ncce if folks here would kick it off ## mpeg dash video streaming over http -- iteresting stuff on http2 herve ruellan (hr): DASH and HTTP/2 (see preso in meeting materials) FDH -- full duplex over http Dan Druta: dunno if that was considered, but need to. "how quickly can u adapt?" hr: yes can adapt but quickly is always difficult ? sees benebit as ? seems lots of complexity w/o lots value didn't understand range option at all jr & roy: request push sounds like GET, how is it diff than pipelined GET ? hr: mnot: http2 designed such that can interleave lots of reqs together. Here client can hint the server about something the client knows. craig tayler(ct): concerned how server push will affect the ? semantics - might be issue hr: yes, there issue here, an intent to have the server respond w/header to client. Then client knows to freeze the signal ? mt: if u know what u need just ask for it. Thinks dash advantage is when server knows more about pacing of segments. E.g., if server sends next segment w/o client asking for it there's advantages. Also, client can notice about net issues and ask for lower quality.... hmmm maybe this looks like multi-get which we didn't do.... ?: involved in dash. Yes there's a manifest file, server can update the manifest. Not clear whether h2 stack offers. Stacks have looked at don't offer this stuff as yet. That's something we need to address. We need a solution for this. Other think is whether push strategies is going to be defined somewhere. questions about flow control mnot: http2 doesn't strictly define how server push works, defined as cache update, not notification to the webapp client. Wonder if we need to notify a listener about cache updates. pm: how can you prioritize things -- we did some of that w/GETs in http2 -- could use that? could be useful. lm: implicit context is using mpeg-dash for realtime. If you have a series of pipelined GETs, you'll get em all. Timing is implicit. If you want to generalize this you might make the timing explicit. ?: not sure dash is useful for RT, but maybe progressive download? mt: there's some useful cases for this. Avoid an XHR ? mnot: don't hear interest in making this a generic extension yet. mnot: Dash folks also have use case to send to client that they have partial segment to send want to send it so client can do what they want mnot: I steered them from partial content to use a different media type to label it. mnot: I will discuss appropriate times for new items with BL