source: wg_materials/ietf75/httpbis-minutes-75.txt @ 851

Last change on this file since 851 was 735, checked in by mnot@…, 11 years ago

add WG materials to repository

File size: 12.5 KB
Line 
1HTTPbis Working Group Minutes
2THURSDAY, July 30, 2009
31300-1500 Afternoon Session I (Room 300)
4
5* agenda and note well
6
7no agenda bashes
8
9lmasinter: 6lowpan (binary http), hybi (bidirectional), iri (revision bof
10announcement) all announced
11
12
13* jreschke: httpbis*-07 summary
14
15drafts published on deadline, changes made since last meeting
16
17content sniffing (155):
18
19lmasinter: uncomfortable in changing the standard about being liberal in
20what they accept, change to normative advice on how this proceeds.
21
22mnot: this is just a clarification, nothing has really changed
23
24lmasinter: is this advice just for HTTP?  or IMAP?
25
26rfielding: the change is just to allow no content type
27
28jreschke: clients used to be forced to use octet-stream when c-type is absent
29
30rfielding: this allows for one or other
31
32lmasinter: content format is defined, but not the behaviour from that; this
33might be ambiguous enough to include abherrant.  The more you open the
34door, the more you might encourage bad behaviour.
35
36mnot: there was a feeling that we didn't want to specify a specific means
37of sniffing.  Noone wanted to mandate sniffing.
38
39rfielding: maybe the last paragraph could be removed
40
41lmasinter: what is the least that you could say?  ...maybe the last
42sentence isn't necessary.
43
44mnot: how does http specify the data type?
45
46rfielding: media type specify how to process the message.  they give an
47interpretation of the data type.  Delete the paragraph.
48
49conclusion: Agreement to remove this.
50
51no comments/discussion on other issues
52
53
54* security
55
56slides from alexey
57http://www.ietf.org/proceedings/08jul/slides/httpbis-0.pdf
58
59noone has said anything on the old issue of splitting sections
60
61question if anyone else has anything to add to this list that can be added
62to the document before next meeting
63
64mnot: who has read this?
65
66response: noone except the author
67
68mnot: we're chartered to cover this subject.  since 2616 doesn't have much
69on this.  jeff is new caretaker on the doc, but there is nothing more known
70to do
71
72jeffh: will rev the doc
73
74cdab: concerned with interaction with other stuff, oauth; this is
75historical
76
77mnot: agree, but it might be too broad if we try to include too much
78detail.  add oauth to the list
79
80rfielding: there were a lot of statements that completely ignored the
81non-browser use of http.  This needs to cover these.
82
83jeffh: that's the first case
84
85mnot: that might be what is addressed by splitting, but we'll have to look
86at that
87
88
89* issues
90
91not going to cover the editorial issues, the editors can deal with those,
92take it to the list
93
94after -07, there have been big changes in p1 and p6.
95
96we're marking important ones as "urgent"
97
98editors have worked out some ideas on how to address these issues and have
99some proposals
100
101#109 entity/representation/variant
102
103entity === representation, so we'll define them as synonyms.
104
105proposal on variant is to remove it: replace it with representation or use
106context to make meaning clear.
107
108eventually use new terms for the outcome of content neg.
109
110conclusion: no comments, disagreement
111
112#69 requested variant
113
114need to get a proposal on this issue
115
116conclusion: nothing to be done as a group
117
118#110 need to work out how to determine how the representation relates to
119the state of the resource
120
121need broader decisions, which might help with such as #22 (etag on a post)
122
123proposal email from mnot on this (see archives)
124http://lists.w3.org/Archives/Public/ietf-http-wg/2009AprJun/0282.html
125
126jhodges: q.. request-URI is resource?
127
128mnot: no, the URI for the resource you've requested
129
130jhodges: correction on 3)...
131
132mnot: on 3) agree that this is the representation of the resource at the
133request-URI.
134
135lmasinter: comment (missed this)
136
137mnot: response ...we want to construct a URI from the host header and any
138path components...
139
140mnot: requested variant is a problem with etag, we need a new term for the
141relationship with etag, then say that the etag applies to the resource
142associated with this representation
143
144jreschke: might be OK with this, obviously needs to think on it; we're
145going to break at least one rfc
146
147rfield: this might not break things, this is just a change that says that
148the server gives direction to clients
149
150cdab: right direction
151
152conclusion: right direction
153
154#188 registries for *-coding headers
155
156mnot: proposed expert review for most, some might need higher
157
158nodding from the room, general agreement
159
160p1#90 delimiting with multipart/byteranges
161
162mnot: not implemented, complex, propose to drop it
163
164conclusion: accepted
165
166p1#131 increase connection limit
167
1682 connection limit isn't followed, in part because pipelining isn't widely
169deployed
170
171mnot: some people don't want to remove limit entirely, so what should it
172be?  research suggests 6 to 8 and we might have some advice for other
173things.
174
175mnot: personally, might be good to have
176
177jreschke: we can't accomodate clients who want to do this
178
179cdab: keepalive interaction with lots of open connections
180
181mnot: resource constrained servers can close connections
182
183mthom: the advice might be useful, knows of applications where very large
184numbers of connections is needed
185
186lmasinter: has something in mind for text, referring to previous limit of 2
187connections
188
189mnot: what are you proposing
190
191lmasinter: no specific number, just advice to limit the number of
192connections as much as possible
193
194mnot: 2 is probably no longer appropriate, but we could do that elsewhere
195
196dstenberg: might be good to downplay the number of connections, we don't
197need that advice in the spec
198
199hum: are you comfortable with having no specific limit?
200
201conclusion: most are comfortable, no hums for discomfort
202
203henrik: still need advice on limiting the number of connections, just
204nothing specific
205
206mnot: agreed
207
208
209p1#145  Host: header is mandatory
210
211ypettersen: if there is an empty authority component we put in localhost for
212iri?
213
214
215p1#159 URI
216
217jeffh: userinfo is in 2616?
218
219henrik: empty host http:/// is not allowed (3 slashes)
220
221lmasinter: general concern, a lot of docs talk about URIs, but they really
222mean http: URIs (and vice versa).  trying to ensure this issue is
223recognised
224
225ipettersen: empty authority generates an error in their implementation,
226(there might be a display error, but that's the intent.)
227
228conclusion: no empty authority, don't allow userinfo
229
230p1#165 date
231
232NOP
233
234p1#173 CR/LF
235
236BNF for chunked encoding and extensions is key/value, but the bnf for the
237chunk extensions allows CR/LF and implementations are likely to just read
238to the end of the line.  propose to remove CR/LF from the BNF, but do this
239for ALL quoted-string instances
240
241conclusion: no objection to this, agreed
242
243p1#184 0.9 support
244
245do we need to still support 0.9?  these wont be sending a Host: header
246
247lmasinter: propose to add gopher
248
249lmasinter: need to think about time-span used to erase legacy stuff
250
251anne: browsers still deal with 0.9 and there might be content out there, he
252hasn't studied this
253
254henrik: the only time we see 0.9 is in broken browsers, or when some other
255protocol is being used, not so much on the Internet, but in constrained
256environments
257
258mnot: we can still take it out, but allow for it in server responses
259
260henrik: they upgrade to 1.+ when they receive (as an intermediary) a 0.9
261
262mnot: we need to discuss this a little more
263
264cdab: is it worth trying to use this to give clients a shove
265
266henrik: 0.9 is used when it's actually something other than http, like
267shoutcast
268
269lmasinter: uses 0.9 to stream
270
271henrik: they use headers
272
273dstenberg: they use ICY instead of HTTP"
274
275mnot: we need to discuss a little more
276
277rfielding: I think that there is universal agreement to remove this
278altogether, make it a history lesson only
279
280hum: can we remove 0.9 support from the spec?
281
282conclusion: yes
283
284
285p2#160 redirect on non-GET
286
287noone follows the advice in 307, 303, 301.
288
289ypetterson: we tried to use 301.302 to select method, users didn't
290understand and servers either didn't respond properly and didn't work.
291301/302 need to just be get.
292
293mnot: 301/302/303 would all be GET if that's the case
294
295ypetterson: redirects have never been tested well
296
297jreschke: we would still have to decide whether this is for POST only for
298all methods, there would be no permanent redirect that is method preserving
299
300mnot: for all, 307 is still method preserving
301
302mnot: is the absence of a permanent method preserving a problem
303
304henrik: 307 can be made permament
305
306mnot: that's ok, but would it be implemented?
307
308jreschke: safari/webkit is the only browser who doesn't do the right thing;
309let's make all redirects use GET and specify exceptions in the opposite way
310
311mnot: let's be explicit on all redirects
312
313henrik: flip the current ones over
314
315rfielding: updated issue ticket with what came from the meeting
316
317jreschke: there might be protocols that rely on the proper semantics of
318301/302, so we probably can't change these too much
319
320mnot: "SHOULD"?
321
322jreshcke: nothing?
323
324mnot: we need some interop
325
326henrik: need some indication and guidance
327
328mnot: maybe need a method preserving flag then
329
330hum: make this a should level requirement?
331
332result: no discomfort, will make this a "SHOULD rewrite to GET"
333
334anne: HEAD should remain as HEAD
335
336mnot: HEAD is an exception
337
338henrik: HEAD is always an exception
339
340mnot: might need to do a complete sweep through the spec for this
341
342anne: OPTIONS also
343
344jreschke: might need to take this back to the list
345
346jeffh: need to think about the security considerations in this as well
347
348mnot: might need to talk about rewriting specific methods rather than a
349blanket
350
351conclusion: need to take this back to the list and talk about specific
352methods
353
354
355
356* milestone -08 issues
357
358p2#43 fragment precedence when redirection includes a fragment
359
360jreschke: related issue #xxx? on whether we should allow for relative URIs
361in Location: header.
362
363mnot: relative headers are widespread
364
365jreschke: We probably should support relative.  Clients generate fragment
366differently depending on whether it's absolute or relative.  Fragment is
367only used in a fragment.  We wouldn't want to specify that.
368
369mnot: not ideally, but this is not just browsers
370
371lmasinter: the fragment identifier is quite browser-specific, it's not used
372in non-browser contexts
373
374mnot: RDF ?
375
376mnot: we need to discuss this, can jrschke send the information to the list
377
378mnot: we might need to document that behaviour
379
380jreschke: there isn't alot of content that relies on this feature, so we
381might be able to change this
382
383conclusion: finish on the list
384
385
386p3#81 (lmasinter)
387
388lmasinter: would like to withdraw this, the scope of applicability is
389fairly narrow; need to soften text
390
391mnot: some apps have a very long list of apps; some people do use this
392
393lmasinter: might need to document when it is useful and when it is not;
394doesn't want the issue any more
395
396lmasinter: shouldn't deprecate, that's overboard
397
398mnot: propose to close the issue
399
400lmasinter: OK
401
402
403
404ypetterson: in Opera, empty authority goes from "" to 0.0.0.0, which ends
405up as a load error
406
407
408* 2231 and HTTPbis
409
410lots of interoperability problems, i18n of filenames is tricky, two
411browsers support it.  agreed to profile 2231 and move to a separate
412document.  Remove from httpbis docs.  document available, and other vendors
413would possibly implement when available.
414
415lmasinter: general issue of file: URIs and that sort of thing
416
417jreschke: has a document on this in WebDAV context
418
419dstenberg: similar encoding issue when doing file upload and
420multipart/form...
421
422cdab: we should look at getting review from email folks
423
424
425* SCTP on HTTP
426
427overview of sctp
428
429problem of pipelining when you don't have enough streams
430
431problem of choosing TCP or SCTP
432
433new issue: avoid chunking using SCTP - SCTP has the mechanisms, maybe it
434can do it
435
436henrik: also asked to help on the draft, in http we need to separate
437message layer from byte stream layer better.
438
439henrik: would need new association per request?
440
441lisa: seems like a flaw?  sounds surprising
442
443lmasinter: (back on selection of method issue) comment on selecting the
444right method, related to old work on HTTP over UDP - learn from our
445failures
446
447fbaker: challenges lmasinter: what are the issues?
448
449lmasinter: need to look at deployment challenge
450
451fbaker: explain URI option
452
453mnot: for me, this is all about proxies/caches to do long haul without end
454user interactions; should also work on mobile networks with configuration
455
456mnot: but we need to split messaging stuff from the TCP stuff
457
458henrik: it's a more general problem than just HTTP, wants to take this to a
459higher layer; SRV records don't really help either
460
461presenting simulation results
462
463mnot: observes that SCTP is good for POST
464
465rfielding: why could this not be done using TCP?
466
467fbaker: TCP connections don't have any knowledge of each other
468
469henrik: sctp doesn't have drawbacks in terms of network fairness
470
471mnot: need to discuss more on the list
472
Note: See TracBrowser for help on using the repository browser.