* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

source: wg_materials/ietf85/minutes.txt @ 2726

Revision 1993, 21.7 KB checked in by mnot@pobox.com, 20 months ago (diff)

first draft of ietf85 minutes

Line 
1
2HTTPbis IETF85 Minutes
3======================
4
5Session I
6=========
7
8WG status
9--------
10
11no bashing
12
13Change overview
14---------------
15
16-21 drafts are out and in LC
17
18overview of changes made in the latest draft (substantial only)
19
20no feedback on the changes that were made in the -21 drafts
21
22ACTION: mnot to create a ticket for https caching exception
23
24Security Properties
25-------------------
26
27mnot raised the issue of security properties of http and the current
28status of the draft (draft-ietf-httpbis-security-properties-05)
29
30barry leiba: not sure that this has any correspondence to reality; if
31we adopted something better than basic then we would not need this
32(according to S Farrell); not sure what this really has to say
33
34mnot: it needs to more specific if it is to be useful, which limits its
35lifetime. This is a product of a bygone era, and we might not have the
36expertise to finish this sort of work, regardless of the merits of improving
37security as a goal
38
39bleiba: suggested that this be moved to the new authentication bof and
40resulting wg
41
42=JeffH: did this as a measure of charity; there might be people who can do
43this within this group; i may not have time to continue this myself
44
45bleiba: murray will do it
46
47roy fielding: we haven't added all the security considerations
48
49mnot: are there missing considerations for the broader web
50
51rf: there are http considerations, but those should be in http
52documents; if there is anything left, then we can look at that
53
54jh: there is a lot of good stuff that should be written down; but I
55haven't done the gap analysis
56
57eliot lear: I agree with the chair that you need implementor interest,
58no matter where the work is done.  Is there that interest?
59
60mnot: there might be some stuff from here that belongs in drafts, but
61some is clearly out of scope
62
63el: please put it to bed
64
65bl: this predates our existing security considerations, which may be
66adequate now
67
68sean turner: this would be good to have and it is part of the charter
69
70bl: can you (st) read this and make a recommendation to the group?
71
72mnot: obviously web security has problems, but whatever we produce has
73to have some relevance
74
75st: you can force the issue by going to last call; or set a time limit
76for "put up or shut up"
77
78mnot: it's still pretty draft-y
79
80
81Other LC Documents
82------------------
83
84rf: last call comments thus far received should take only a short time to
85resolve
86
87rf: concerned about the lack of review in p5
88
89mnot: jreschke is expecting to go to proposed standard and to move to full
90standard once we've gone through the http/2 process and discovered all the
91bugs
92
93mnot: can we go full standard?
94
95alexey melnikov: no
96
97
98active issues
99-------------
100
101jr: (most of these arefrom Dan Winship's review of p1; I haven't
102entered those for p2 yet)
103===395
104rf: do we allow some leniency
105mnot: this could just be statements of fact
106rf: ok
107mnot: do we have other requirements around connection: close ?
108mnot: it could be prose
109ACTION: make SHOULD statements on Connection header handling prose
110instead of 2119 language
111
112### 397
113
114ACTION: put the exception for OPTIONS request to a proxy and the resulting URI
115
116### 22
117
118just tbd, no real issue
119
120### 350
121mnot: we can close this one
122
123### mnot's WGLC p1 review
124
125rf: asks for fresh eyes over the drafts
126
127mnot: asks about what is specific to HTTP as opposed to HTTP/1.1; what
128can we do to improve the way that this could be made reusable for
129HTTP/2
130
131no conclusion
132
133#### What are the parsing requirements for obs-fold with respect to the MUST?
134
135rf: if you can find no interoperable folding implementations, then we
136can remove it from the grammar [[scribe: may not have got this right,
137action more important to capture]]
138
139ACTION: mnot to run some tests on folding to understand its interoperability
140
141#### shared caching on https
142
143rf: the statement in question only applies to agent-side
144intermediaries and user agents, not to content accelerators, which are
145part of the origin server
146
147rf: some user agents use a common interface to make the request, then
148have separate logic to decide how that information is made available
149to other users
150
151rf: to know whether it is safe to send to other servers, you have to
152know the content
153
154mnot: you can use Cache-Control
155
156...some disagreement here
157
158roberto peon: there are transformative intermediaries; we don't need to
159specify this
160
161mnot: need to know who this applies to
162
163rf: this applies to libraries in clients
164
165mnot: segregation... a shared cache can even apply to the same box
166
167martin t: 'never "public"' contradicts what has been said about caching rules
168
169paul leach: override
170
171Patrick McManus: on a phone, different apps can share the same network context
172
173ACTION: follow up on this issue
174
175
176### on US-ASCII or a superset of it
177
178mnot: moving on
179
180
181### on whitespace between start-line and headers
182
183rf: I thought there was some guidance on this
184
185mnot: we should find that text
186
187rf: S19 should not have had any normative requirements in it
188
189mnot: we can remove this then
190
191mnot: think about consolidating the list construction rules that are
192specifically called out for Transfer-Coding
193
194rf: this defines the framing and more explicit rules were asked for
195
196mnot: ok
197
198### for render as complete or consider as complete
199
200kevin falk: are you prohibited from using particular code blocks to users?
201
202rf: the important consideration is that the user is able to learn that the
203information is incomplete
204
205julian r: that is getting ignored in practice
206
207brian smith: we (Mozilla) ignore this requirement, pages are already displayed
208
209mnot: would it be OK to show status in the web console?
210
211rf: not really
212
213bs: there are UX considerations that make this more difficult than it
214would appear
215
216bs: there's not much difference between XHR and the render as HTTP clients
217
218jr: we could add an indicator
219
220ted hardie: visual indicators are not necessarily universally applicable
221
222rpeon: there is a lot of confusion stemming from this statement,
223prefer the parenthetical
224
225bsmith: no idea about how XHR works, though it does have streaming
226modes; script developers are important
227
228will chan: chrome ux people didn't like the idea of having something in chrome
229
230rf: this is a safety/security feature
231
232kfalk: incomplete !== error
233
234julian: there is a related issue about truncated *downloads* (as in
235"save as"); Eric Lawrence once blogged about it
236(<http://blogs.msdn.com/b/ieinternals/archive/2011/03/09/browsers-accommodate-incorrect-http-content-length-and-sites-depressingly-depend-on-it.aspx>)
237
238pmcm: rathole, we (Moz) do very little prescribed error handling and
239it's strange spending time on this when there are many others; tried
240to rollback rendering when MD5 sum failed, got immense push back
241
242mnot: maybe this should be prose
243
244ACTION: Roy to make this prose text in the security considerations
245
246#### whitespace tolerance in headers and the requirement
247to product a 400 when the message doesn't match the grammar
248
249#### no enumeration for the hop-by-hop headers that are not required to be
250added to Connection header.
251
252rf: this will be forwarded if they aren't in the connection header;
253having a list would cause problems with intermediaries that pass these
254
255mnot: this could surprise some people and should be called out
256
257rf: this should be noted as a change from 2616
258
259jr: we already have this
260
261mnot: we probably need a callout for this one
262
263rf: I'm trying to reduce the number of occurences of this; they don't
264help the people reading the document for the first time
265
266
267Server Ranges
268-------------
269
270<http://tools.ietf.org/html/draft-kfall-httpbis-server-ranges-00>
271
272mnot: this doesn't really mess with semantics, it only messes with
273intermediaries to the extent that range requests are hard to do anyhow
274
275mnot: streaming and ranges require the complete size to be known,
276changing the length would not be possible
277
278kfall: that is not part of the proposal
279
280pleach: does this work with unmodified implementations?
281
282kfall: not known
283
284pleach: profile...
285
286mtho: prefer might help to signal (all/some)
287
288mnot/kfall: makes sense
289
290bsmith: if the server provided less, would we be able to render it?
291the spec seems arranged around the idea of a "complete message", this
292might need to be re-addressed
293
294mnot: disagree, this should be addressed and if you can find something
295that isn't, please bring it up
296
297rf: yes
298
299kfall: what now?
300
301rf: how much testing have you done with clients that expected the bits
302that they requested?
303
304kfall: that's in part why we asked
305
306rf: testing first might determine how to proceed with this, if this
307kills an existing client, then this is a no-go
308
309mnot: 206 is close enough
310
311mnot: mumble, mumble, vary...
312
313rf: vary isn't so relevant in this case, it's for selecting representations
314
315mnot: fine
316
317ACTION: kfall to review -p5
318
319draft-fielding-http-key-01
320--------------------------
321
322A not-dumb Vary header
323
324roy outlines the idea that you can make a request without headers to
325avoid the fingerprinting thing, detect the variances that might occur,
326then make more requests
327
328cyrus daboo: key == too generic
329
330roy: I don't care if its confusing, and number of bytes on the wire
331
332jr: application/*+json, globbing conneg
333
334roy: no, breaks stuff
335
336
337
338Session II
339==========
340
341ticket #385: upgrade mechanism
342------------------------------
343
344<http://trac.tools.ietf.org/wg/httpbis/trac/ticket/385>
345
346### TLS Upgrade for HTTPS URIs
347
348See thread rooted here: http://lists.w3.org/Archives/Public/ietf-http-wg/2012OctDec/0143.html
349
350mnot will send the message suggested in that above message to the tls chairs
351and show up in the TLS session this afternoon
352
353### Upgrade for HTTP URIs
354
355Gabriel M. is going to present on upgrade-based negotiation for http/2.0 --
356which is one approach to addressing the issues in the "http uris" section of
357the issues outlined in the
358<http://lists.w3.org/Archives/Public/ietf-http-wg/2012OctDec/0143.html> mail
359msg
360
361roy at mike: don't need to prefix the header fields; they're just header fields
362
363mnot: it's side channel info, for optimizing
364
365roy: as soon as sent in http1.1 they're just a header field, register them,
366don't need prefix
367
368jhil: would those http2 things get stripped out?
369
370gabriel m (gm): yes
371
372<mbelshe> mic: have any tests been run to confirm viability in the wild? as
373presented before, data shows port 80 has trouble with non-http1.1 protocols.
374or do we just want to ignore that?
375
376mnot to mike belshe (mb) -- we're getting there
377
378gm @mic: <discussing fine points of upgrade>
379
380phb@mic: 1st thing is successful upgrade, 2nd thing is what to do if it fails
381
382jhil: is there a timing issue with expect 100 continue ?
383
384mnot: do an upgrade and combine with expectation?
385
386roy: wouldn't normally do that. the 1st request you make shouldn't be a large
387state changing operation
388
389roy: so you send options or GET first (so it's not a packet loss issue)
390
391jhil: so perhaps need note about that in spec
392
393mnot: discussion we need to have is whether a upgrade like this is workable
394for us -- in hybi they figured that about 70% conns using this would be
395successful, rest would fail
396
397fielding: you don't upgrade a request while sending a large body and Expect
398100-continue -- it is simply not a use case that is relevant. It might work
399quite well, but it simply isn't worth being concerned about.
400
401mnot: so perhaps deploying using this it'd encourage the internet to upgrade,
402but only if we have fast failure fallback
403
404patrick mcmanus (pm) @mic : in FF, doing 6455 (?) the TLS success rates are
405substantially better than the plain success rates. Roughly 80% with TLS, maybe
406almost 70% with plain HTTP
407
408<Eliot Lear> mic: what did success mean in this case?
409
410salvatore@mic: its true we had not so good success rate with plain upgrade,
411but lots of boxes will be upgraded, and they (?) just relaeased boxes with
412spdy support and [we'll see what happens (?)]
413
414mnot: there'll be several versions of the protocol out there because we're
415going to try various approaches
416
417mnot: the upgrade mech needs certain capabilities, eg supporting opportunistic
418use of TLS
419
420mnot: calling for data on how upgrades are working -- with data we have now,
421it seems if we design this thing well it';ll either succeed or fail fast ----
422wondering about what folks thing whegther we should go down "this path"
423
424<Eliot Lear> mic: should pursue this path, but need more data.
425
426pm: let's talk about the other approaches
427
428mnot: ok, another approach is "Using a SRV (or other DNS) record" (from
429<http://lists.w3.org/Archives/Public/ietf-http-wg/2012OctDec/0143.html>
430
431mnot: have heard that there is general interest in using DNS as a mech, and do
432folks think we shouldn't use SRV?
433
434<Eliot Lear> Mic: NOT in favor of SRV.
435
436ekr: this is 1st time mention srv, realise that the TLS server id check you do
437is with name you started with, not with the one srv gives you
438
439mnot: yes
440
441jeffh: <thinks rfc6125 discusses this>
442
443<Eliot Lear> Mic: What are the goals? Please be specific!!
444
445<mbelshe> mic: is there a serious proposal around srv? or is this at the
446brainstorm stage?
447
448mnot: we're at the brainstorm stage
449
450cyrus d (cd) @mic: i get http://example.com and running http/2 on that, but on
451example.com:88 running http/1 ....
452
453pm: if uri contains port, then we're not going to do the srv lookup (?)
454
455phb@mic: the dns is where u make assns re names; should bind names & prots "in
456dns"; there's practical issues with doing this; in how clients use dns; don't
457nec use srv; want to use dnssec; so going to use "new dns" world anyway; and
458so may want srv+ <eg need to invent new dns stuff>
459
460pm: this is more work everywhere, u can set this up; and so in one round trip
461get all info u need, can mux with this btwn http 1 & 2 and whatever, <missed
462stuff> so this approach gives some nice benefits
463
464? @mic: if u get a diff port from srv, do you use that?
465
466mnot: there's a lot sec related concerns here need to be careful
467
468eric nygren (en): having srv records would be an advantage; addtnl benefit is
469having sep servers handling http/1 and http/2 -- help deployment
470
471mnot: inclined to say this (srv/dns stuff) will be a work item for us
472
473mnot: upgrade mech should start in main draft ...3d mech " 2) Using a response
474header to hint that HTTP/2 is available on another port" from
475<http://lists.w3.org/Archives/Public/ietf-http-wg/2012OctDec/0143.html>
476
477<Eliot Lear> ted: there are still often many different http servers running on
478different ports of the same host
479
480roberto: <comment about upgrade detail>
481
482Martin Thomson: Enumeration is: TLS nextproto, HTTP upgrade, srv or other DNS
483record, alternate-protocol header
484
485mnot: start developing DNS based, and a response header based mechanism as
486well. Selected editors for core HTTP work, Martin Thompson, Aleksy Melnikov,
487and Julian Resshke will be helping out
488
489Eliot Lear: I volunteer to develop at least one DNS-based proposal
490
491mnot: don't want to put all work on them
492
493
494header compression
495------------------
496
497<http://trac.tools.ietf.org/wg/httpbis/trac/wiki/HTTP2Compression>
498
499Herve Ruellan slides on HTTP Header Encoding Results
500http://www.ietf.org/proceedings/85/slides/slides-85-httpbis-1.pdf
501
502jhil: think about impact on mobile devices such as power required ?
503
504agl @mic: so now spdy compression has issues with trying to avoid crime attack
505
506rp: but its still useful as baseline
507
508mnot: see github.com/http2/http_samples - this is a corpus of header samples;
509har files from pcap captures.
510
511cd: what about webdav et al?
512
513mnot: if you want to submit traces for that, please do
514
515jhil: prob need some enterprise traces because of strange cross-domain cookies
516we see, but need to anon them
517
518mnot: ... but not concerned about pathological cases
519
520jhil: but might help show which compress scheme is better
521
522mnot: next thing come up with script that analyses this stuff, and eg can emit
523a pathological case, and then run compression algs on it and see how it works
524
525rp: can do this in python & work with mnot
526
527roy: http2 is not a minor hack -- need to do it carefully -- perhaps we should
528have better encoding for header fields, eg cookies are huge, this could be
529binary, if we define an encoding, then can encode cookies when sending over
530http and get diff comp results
531
532mnot: we can define new headers that have diff encodings eg binary, and then
533downgrade them to eg txt when sending over http/1
534
535roy: a cook header field, obviously can't change that due to existing
536browsers, but browsers just store it and replay it; new thing doesn't have to
537be compat with existing cookies, so if svr has choice to send short cook
538rather than long one....
539
540mnot: two diff things here, one is http1 <-- > http/2 <--> http/1 w/o loss;
541the other is doing stuff in http/2 that are new ( and then needing to
542downgrade new stuff into http/1 as nec )
543
544mnot: if u can compress a bunch of requests down to fit in one underlying pkt,
545then that's very powerful, esp in mobile world; inclined to keep that in mind
546when selecting compression approach; .need to keep memory & cpu & power
547overheads in mind
548
549rp @mic: web app developers shouldn't have to opt their site to "make it fast"
550-- rather should make protocol fast
551
552mnot: yes
553
554phb: what about patent issues in compression?
555
556mnot: they'll have to disclose
557
558phb: if u make disclosure call now it has implications down the road
559
560mnot: we'll deal with that later
561
562mnot: we prob won't choose perfect comp mech for all time, thus negotiate comp
563mech?
564
565mnot: if upgrade mech is adequate, then can include comp mech in that, but if
566too much optionality there, that's interop probs
567
568mnot: would be nice if can put it into debug mode to see stuff on wire -- so
569question to be able to turn comp on/off ?; .thoughts on this?
570
571rp: perhaps can put stuff in there to make debugging "easy" rather than "turn
572it off"
573
574mnot: roberto wants to talk about http/w compression
575http://tools.ietf.org/html/draft-rpeon-httpbis-header-compression-00
576
577roy: yes, the compression ratio gets better if you send garbage on the wire
578
579roy: notes that a fixed id space is essentially a registry in machine readable
580form
581
582rp: yes; but its not a reg that needs to be maintained after its created
583
584martin thompson (mt): dont understand where huffman encoding comes into play?
585
586rp: draft needs work; what is huffman coded is the text in the headers. ran
587analysis over sample of headers, and then used that to gen id space
588
589<PHB> seems to me that we are maybe doing this the wrong way
590
591rp: hopefully impl code for this is better to understand than the I-D at this
592point :)
593
594mnot: so we know sorta where we going on compression stuff, want to get impls
595plugged into the http2 namespace on github -- the more visible we can make
596this the better
597
598<Martin Thomson> the question was: do you have a note well on the repo
599
600#387: server push
601-----------------
602
603We need more data / experience.
604
605
606Other Issues
607------------
608
609### Flow Control
610
611gabriel montenegro (gm) -- flow control principles for http 2
612
613hildjj: we need TSV help for this part.
614
615roy: init exchange over tcp, client begins; with this do you expect server to
616send anything first wrt state?
617
618gm: in spdy there's default 64k per stream
619
620rp: basically need default for safety reasons, but a better FC mech than spdy3
621exists, hopefully will be proposed, can make larger than 64k by defualt
622
623ted hardie(th): what impact if doing multipath tcp under this?
624
625gm: yes need to figure out interaction with newish tcp stuff under it
626
627mnot: is FC tightly bound to what xport's properties are?
628
629gm: yes
630
631rp: <nods yes>
632
633jhil: we need early involvement by transport folks, don't wanna make buffer
634bloat worse
635
636rp: don't think that's possible
637
638will chan (wc): would hope that FC in http/2 doesn't subvert xport FC; want to
639make sure we saturate link; this should be one of the principles
640
641gm: thinks link saturation depends on how the <sliding window / credits >
642work; don't have to solve now
643
644alison mankin (am): if receiver has FC turned off by intermediary, that messes
645stuff up.
646
647gm: but receiver controls it for his hop. is concerned about middleboxes at
648http layer; at that layer the proxy has to heed what endpoint (receiver)
649wishes. still concerned on traps that may be there
650
651rp: there's finite buffering available for entire path length; if receiver
652says stop, it'll stop eventually; but as soon as an intermediate is in the
653path, they have influence on FC
654
655gm: we need to codify the rules in the base spec
656
657mnot: gm will have draft coming out, please review. FC will get a new issue #
658
659
660### Priorities
661
662pm: priorities need discussion
663
664mnot: will create issue for that (framing, diff frame sizes)
665
666rp: want to agree and disagree wrt priortzn stuff -- need more experimentation
667
668mnot: sure, may defer disc of these issues, but want to get em written down
669
670
671### Mapping to TCP
672
673eric nygren (en): mapping to tcp -- need to disc
674
675mnot: yes, need optional draft on "how i use tcp"
676
677rp: agree with en that'll be issue, might wanna address earlier, need to get
678sec folk thinking about that
679
680en: also has implications for prototcol upgrade mech, signalling may make this
681easier or harder
682
683
684### Framing
685
686gm: did u raise issue on framing itself?
687
688mnot: it will get raised; specific concern; useful for e.g., sendfile()
689
690Wrapup
691------
692
693mnot: am gratified to see folks working on drafts; continue doing that; will
694use wiki to record current state of proposals; interlink to issue #s; will
695also use github; will hand out access to (sub) repositories; the actual drafts
696will be in ietf subversion service;
697
698mnot: f2f meetings are effective for work like this, involves lots of folks,
699need to confirm decisions on list, tho possiblities of interim meetings, may
700be good idea here in earlier phase like this, current plan is interim mtg in
701Jan 2013, 2..3 days, offer from Ian Fette to host in Tokyo, need to get dates,
702maybe mid Jan to early Feb, pls send dates ideas to mnot
703
704mnot: any more biz ?
705
706phb: discussing compression -- was of msgs, not conversations -- in mobile --
707sending "pages" with lists of links --- but maybe do html-conscious
708compression ?
709
710jhil: don't we get some of that with svr push?
711
712en: if start with http1, include an encoded blob of handshake framing?
713
714mnot: that's in category of cool tricks we could play.
715
716mnot: keep drafts coming, will send minutes out soon, if hold this interim
717mtg, want to make it useful
718
719adjourned
Note: See TracBrowser for help on using the repository browser.