HTTPbis Working Group Minutes THURSDAY, July 30, 2009 1300-1500 Afternoon Session I (Room 300) * agenda and note well no agenda bashes lmasinter: 6lowpan (binary http), hybi (bidirectional), iri (revision bof announcement) all announced * jreschke: httpbis*-07 summary drafts published on deadline, changes made since last meeting content sniffing (155): lmasinter: uncomfortable in changing the standard about being liberal in what they accept, change to normative advice on how this proceeds. mnot: this is just a clarification, nothing has really changed lmasinter: is this advice just for HTTP? or IMAP? rfielding: the change is just to allow no content type jreschke: clients used to be forced to use octet-stream when c-type is absent rfielding: this allows for one or other lmasinter: content format is defined, but not the behaviour from that; this might be ambiguous enough to include abherrant. The more you open the door, the more you might encourage bad behaviour. mnot: there was a feeling that we didn't want to specify a specific means of sniffing. Noone wanted to mandate sniffing. rfielding: maybe the last paragraph could be removed lmasinter: what is the least that you could say? ...maybe the last sentence isn't necessary. mnot: how does http specify the data type? rfielding: media type specify how to process the message. they give an interpretation of the data type. Delete the paragraph. conclusion: Agreement to remove this. no comments/discussion on other issues * security slides from alexey http://www.ietf.org/proceedings/08jul/slides/httpbis-0.pdf noone has said anything on the old issue of splitting sections question if anyone else has anything to add to this list that can be added to the document before next meeting mnot: who has read this? response: noone except the author mnot: we're chartered to cover this subject. since 2616 doesn't have much on this. jeff is new caretaker on the doc, but there is nothing more known to do jeffh: will rev the doc cdab: concerned with interaction with other stuff, oauth; this is historical mnot: agree, but it might be too broad if we try to include too much detail. add oauth to the list rfielding: there were a lot of statements that completely ignored the non-browser use of http. This needs to cover these. jeffh: that's the first case mnot: that might be what is addressed by splitting, but we'll have to look at that * issues not going to cover the editorial issues, the editors can deal with those, take it to the list after -07, there have been big changes in p1 and p6. we're marking important ones as "urgent" editors have worked out some ideas on how to address these issues and have some proposals #109 entity/representation/variant entity === representation, so we'll define them as synonyms. proposal on variant is to remove it: replace it with representation or use context to make meaning clear. eventually use new terms for the outcome of content neg. conclusion: no comments, disagreement #69 requested variant need to get a proposal on this issue conclusion: nothing to be done as a group #110 need to work out how to determine how the representation relates to the state of the resource need broader decisions, which might help with such as #22 (etag on a post) proposal email from mnot on this (see archives) http://lists.w3.org/Archives/Public/ietf-http-wg/2009AprJun/0282.html jhodges: q.. request-URI is resource? mnot: no, the URI for the resource you've requested jhodges: correction on 3)... mnot: on 3) agree that this is the representation of the resource at the request-URI. lmasinter: comment (missed this) mnot: response ...we want to construct a URI from the host header and any path components... mnot: requested variant is a problem with etag, we need a new term for the relationship with etag, then say that the etag applies to the resource associated with this representation jreschke: might be OK with this, obviously needs to think on it; we're going to break at least one rfc rfield: this might not break things, this is just a change that says that the server gives direction to clients cdab: right direction conclusion: right direction #188 registries for *-coding headers mnot: proposed expert review for most, some might need higher nodding from the room, general agreement p1#90 delimiting with multipart/byteranges mnot: not implemented, complex, propose to drop it conclusion: accepted p1#131 increase connection limit 2 connection limit isn't followed, in part because pipelining isn't widely deployed mnot: some people don't want to remove limit entirely, so what should it be? research suggests 6 to 8 and we might have some advice for other things. mnot: personally, might be good to have jreschke: we can't accomodate clients who want to do this cdab: keepalive interaction with lots of open connections mnot: resource constrained servers can close connections mthom: the advice might be useful, knows of applications where very large numbers of connections is needed lmasinter: has something in mind for text, referring to previous limit of 2 connections mnot: what are you proposing lmasinter: no specific number, just advice to limit the number of connections as much as possible mnot: 2 is probably no longer appropriate, but we could do that elsewhere dstenberg: might be good to downplay the number of connections, we don't need that advice in the spec hum: are you comfortable with having no specific limit? conclusion: most are comfortable, no hums for discomfort henrik: still need advice on limiting the number of connections, just nothing specific mnot: agreed p1#145 Host: header is mandatory ypettersen: if there is an empty authority component we put in localhost for iri? p1#159 URI jeffh: userinfo is in 2616? henrik: empty host http:/// is not allowed (3 slashes) lmasinter: general concern, a lot of docs talk about URIs, but they really mean http: URIs (and vice versa). trying to ensure this issue is recognised ipettersen: empty authority generates an error in their implementation, (there might be a display error, but that's the intent.) conclusion: no empty authority, don't allow userinfo p1#165 date NOP p1#173 CR/LF BNF for chunked encoding and extensions is key/value, but the bnf for the chunk extensions allows CR/LF and implementations are likely to just read to the end of the line. propose to remove CR/LF from the BNF, but do this for ALL quoted-string instances conclusion: no objection to this, agreed p1#184 0.9 support do we need to still support 0.9? these wont be sending a Host: header lmasinter: propose to add gopher lmasinter: need to think about time-span used to erase legacy stuff anne: browsers still deal with 0.9 and there might be content out there, he hasn't studied this henrik: the only time we see 0.9 is in broken browsers, or when some other protocol is being used, not so much on the Internet, but in constrained environments mnot: we can still take it out, but allow for it in server responses henrik: they upgrade to 1.+ when they receive (as an intermediary) a 0.9 mnot: we need to discuss this a little more cdab: is it worth trying to use this to give clients a shove henrik: 0.9 is used when it's actually something other than http, like shoutcast lmasinter: uses 0.9 to stream henrik: they use headers dstenberg: they use ICY instead of HTTP" mnot: we need to discuss a little more rfielding: I think that there is universal agreement to remove this altogether, make it a history lesson only hum: can we remove 0.9 support from the spec? conclusion: yes p2#160 redirect on non-GET noone follows the advice in 307, 303, 301. ypetterson: we tried to use 301.302 to select method, users didn't understand and servers either didn't respond properly and didn't work. 301/302 need to just be get. mnot: 301/302/303 would all be GET if that's the case ypetterson: redirects have never been tested well jreschke: we would still have to decide whether this is for POST only for all methods, there would be no permanent redirect that is method preserving mnot: for all, 307 is still method preserving mnot: is the absence of a permanent method preserving a problem henrik: 307 can be made permament mnot: that's ok, but would it be implemented? jreschke: safari/webkit is the only browser who doesn't do the right thing; let's make all redirects use GET and specify exceptions in the opposite way mnot: let's be explicit on all redirects henrik: flip the current ones over rfielding: updated issue ticket with what came from the meeting jreschke: there might be protocols that rely on the proper semantics of 301/302, so we probably can't change these too much mnot: "SHOULD"? jreshcke: nothing? mnot: we need some interop henrik: need some indication and guidance mnot: maybe need a method preserving flag then hum: make this a should level requirement? result: no discomfort, will make this a "SHOULD rewrite to GET" anne: HEAD should remain as HEAD mnot: HEAD is an exception henrik: HEAD is always an exception mnot: might need to do a complete sweep through the spec for this anne: OPTIONS also jreschke: might need to take this back to the list jeffh: need to think about the security considerations in this as well mnot: might need to talk about rewriting specific methods rather than a blanket conclusion: need to take this back to the list and talk about specific methods * milestone -08 issues p2#43 fragment precedence when redirection includes a fragment jreschke: related issue #xxx? on whether we should allow for relative URIs in Location: header. mnot: relative headers are widespread jreschke: We probably should support relative. Clients generate fragment differently depending on whether it's absolute or relative. Fragment is only used in a fragment. We wouldn't want to specify that. mnot: not ideally, but this is not just browsers lmasinter: the fragment identifier is quite browser-specific, it's not used in non-browser contexts mnot: RDF ? mnot: we need to discuss this, can jrschke send the information to the list mnot: we might need to document that behaviour jreschke: there isn't alot of content that relies on this feature, so we might be able to change this conclusion: finish on the list p3#81 (lmasinter) lmasinter: would like to withdraw this, the scope of applicability is fairly narrow; need to soften text mnot: some apps have a very long list of apps; some people do use this lmasinter: might need to document when it is useful and when it is not; doesn't want the issue any more lmasinter: shouldn't deprecate, that's overboard mnot: propose to close the issue lmasinter: OK ypetterson: in Opera, empty authority goes from "" to 0.0.0.0, which ends up as a load error * 2231 and HTTPbis lots of interoperability problems, i18n of filenames is tricky, two browsers support it. agreed to profile 2231 and move to a separate document. Remove from httpbis docs. document available, and other vendors would possibly implement when available. lmasinter: general issue of file: URIs and that sort of thing jreschke: has a document on this in WebDAV context dstenberg: similar encoding issue when doing file upload and multipart/form... cdab: we should look at getting review from email folks * SCTP on HTTP overview of sctp problem of pipelining when you don't have enough streams problem of choosing TCP or SCTP new issue: avoid chunking using SCTP - SCTP has the mechanisms, maybe it can do it henrik: also asked to help on the draft, in http we need to separate message layer from byte stream layer better. henrik: would need new association per request? lisa: seems like a flaw? sounds surprising lmasinter: (back on selection of method issue) comment on selecting the right method, related to old work on HTTP over UDP - learn from our failures fbaker: challenges lmasinter: what are the issues? lmasinter: need to look at deployment challenge fbaker: explain URI option mnot: for me, this is all about proxies/caches to do long haul without end user interactions; should also work on mobile networks with configuration mnot: but we need to split messaging stuff from the TCP stuff henrik: it's a more general problem than just HTTP, wants to take this to a higher layer; SRV records don't really help either presenting simulation results mnot: observes that SCTP is good for POST rfielding: why could this not be done using TCP? fbaker: TCP connections don't have any knowledge of each other henrik: sctp doesn't have drawbacks in terms of network fairness mnot: need to discuss more on the list