HTTP Working Group Meeting, 8, 10 December 1997 Chair: Larry Masinter Minutes were recorded by Jim Whitehead, Daniel Veillard and Rohit Khare, edited by Larry Masinter. These minutes combine the notes from Monday December 8 and Wednesday December 10. Jim Gettys led a review of issues from the issue list. Most of these issues reflect edits that were already in draft-ietf-http-v11-spec-rev-01.txt but needed additional review. New issue AUTH-INFO-SYNTAX: New issue, reviewed for the group, but no conclusion. New issue DIGEST-PROBS: Reviewed briefly, but take to the list. Henrik presented CONTENT-ENCODING and a proposed solution: add to accept-encoding "*" (meaning all encodings), "identity" (meaning no encoding), and qvalues (for yes and no). There are some proxy issues with respect to content-encoding, and transfer encoding: a Content-Encoding can go through proxies, but a Transfer-Encoding cannot. Dropping q values would avoid 406 codes from existing HTTP/1.1 servers, but would not fix some current problems. After discussion on whether any clients will support this, and a proposal of a "Decline-Encodings" header, the preferred solution is to use the solution in the issues list. This will be discussed more on the mailing list. Issue PUT-RANGE: Few people had reviewed the rev-01 draft. There was no implementation experience with this in the room ( Henrik claims that he might have implemented something similar, once). On Wednesday, we discussed that the use might be in a proxy which updates a byterange of its _cached_ copy at the same time it passes back to the origin. But 1) in WebDAV, many proxies may have partial views of the update changes. So, you'd have to recheck e-tags to update caches -- and redownload all that material. 2) more to the point, editing usually adds and removes material, which put-range does not do. This feature requires a robust version number to detect the feature; a server that did PUT but not byteranges would REPLACE the whole resource; thus it should be forbidden, not just discouraged. We agreed to leave PUT with byte-ranges out of HTTP/1.1 (discouraged or forbidden). The WebDAV group may propose a PATCH method to handle this capability instead. Issue DIGEST_SYNTAX: was reviewed, but will be discussed on the list. Issue PROTECTION-SPACE: People are happy with the current language, but current implementations don't behave as specified; the spec doesn't break any existing implementation. We'll go forward with the current language in rev-01. Issue CONTRADICTION: The Proxy-Length change introduced an error. The proposal in rev-01 was accepted. Issue IMS_INM_MISMATCH: The proposal in rev-01 was accepted. Issue BYTERANGE_SYNTAX: This is a subtle problem; some implementors seem to want to be too smart. We need to specify that you should do the "dumb" thing, not the "smart" thing. The proposal in rev-01 was accepted. Issue PROXY-REDIRECT: The functionality is desirable (e.g., for switching to a new protocol in the future, via use of proxies), but someone from needs to develop a draft to address this problem. Resolution: add note to spec. to deprecate 305, and note that it should not be implemented. Document security problem with this status code. Issue RE-AUTHENTICATION-REQUESTED: Most current clients do not discard credentials when they receive a 4xx status code. Roy Fielding had suggested that an extra header should be used to inform the client to discard credentials. One problem with this approach is the server does not know if the client really has discarded credentials. Resolution: add a note to the security considerations indicating that this issue exists, but has not been addressed in the specification. This should not be in the Draft Standard 1.1 spec. Scott Lawrence may develop an Internet-Draft to address this issue outside of the Draft Standard. Issue RANGE_WITH_CONTENTCODING: Should range requests apply before or after content coding? On Wednesday, we agreed to "last call" the resolution in rev-01. Issue TRAILER_FIELDS: Discussion on why this is needed, and whether clients are likely to support this. On Wednesday, we agreed to "last call" the resolution in rev-01. Issue HOST: Resolution in rev-01 is closed. Issue RE-VERSION: (Wednesday) If you DON'T upgrade the request, you'll get a lower version answer for your cache -- a subsequent 1.1 request CAN'T be satisfied from a 1.0 cached response. 1.0 requests can be answered from 1.1 responses. Richer responses can always be used to answer simpler queries. Henry Sanders will post his remarks to the list, and then RE-VERSION will be closed. New issue DIGEST-SCALING: (Wednesday) RFC 2069 had one concern raised: Digest does not work well with proxies and not at all across multiple servers. Paul Leach will soon post to the list a small tweak which addresses both (and issue a new I-D?). ================================================================ State Management: Dave Kristol reviewed State Management Timeline: - December, 1995 [sic!] state management sub-group formed - April, 1996 first Internet Draft, http-state-mgmt-00 - July, 1996 I-D submitted as prospective RFC, minor wording tweaks for IESG in Oct., Nov. - February, 1997 RFC 2109 issued RFC 2109 Issues: - compatibility (interoperability): client behavior on unrecognized attributes - privacy especially "unverifiable transactions" user - interface requirements arising from support of privacy protection RFC 2109 Follow-up, since February: - compatibility (interoperability) Define Set-Cookie2 response header - privacy and user interface requirements temporarily delete contentious parts Major Changes Since RFC 2109: - Set-Cookie -> Set-Cookie2 - add CommentURL attribute - add Discard attribute - add Port attribute - fuss with Domain, domain matching - clarify behavior for unrecognized or duplicate attributes State Management Progress Plan - current draft: http-state-man-mec-05 "pure protocol" (more or less) - do Last Call on -05 - restore privacy/user interface parts - discuss and seek consensus - reach Last Call - submit result to supersede RFC 2109 Where to look: - DMK's cookie page http://portal.research.bell-labs.com/~dmk/cookie.html - Current draft draft-ietf-http-state-man-mec-05.txt - HTTP-WG mailing list http://www.ics.uci.edu/pub/ietf/http/ - http-state mailing list http://www.bell-labs.com/mailing-lists/http-state Following the slide presentation, there was discussion on the privacy considerations in the draft. Ted Hardie: In Comment-URL, the URL could potentially be a non-HTTP URL, and this issue needs to be addressed. Dan Jaye presented some information on further work on trust labels. State Management will proceed as an informal working group. There is no plan to form a formal IETF working group at this point. On Wednesday, it was reported that a small group of developers reviewed the outstanding issues with state management and found one technical and one political problem left. Technically, domain matching does not work with flat (intranet) domains where "foo." is an FQDN. The political issue is user notification of cookies from unverifiable transactions -- should people be tracked by an external source of inline images or applets or audio? ================================================================ Extensions Josh Cohen gave a presentation on OPTIONS and PEP: Motivation - Extensibility Both OPTIONS and PEP were intended to provide more robust extensibility mechanisms for HTTP/1.1. Extensibility of HTTP/1.1 -Clients can advertise some kinds of capabilities using Accept-* headers. -Clients and Servers can prevent inappropriate caching by 1.1 Proxies using Vary and Cache-Control. This may result in cache misses that could have been hits, but can if used correctly prevent hits that should have been misses. -Clients have _very_ limited ability to discover whether or not a Server implements a given extension. The response version number and the OPTIONS method are the only mechanisms available. -No mechanisms for discovering which optional or extension headers are supported. -No mechanisms for discovering which optional or extension headers are supported, or what definition of a given header is implemented. -Discovery of Proxy capabilities by either Clients or Origin Servers is worse. History -These issues have been discussed on the WG list since (at least) early 1995, insufficient consensus has been reached to incorporate stronger general purpose discovery mechanisms into the standard. Issues Resolutions for Draft Standard -OPTIONS: Incorporate only the minimal definition (no defined body for OPTIONS response, only use the Allow header field). -PEP: Possibly proceed as an Experimental RFC, nothing in Draft Standard. Futures -Extensions to HTTP are being actively developed, both by and within IETF (UAhint, Safe, Content Negotiation, State Management, WebDAV, Hit Metering) Guidelines for Extensions -HTTP-WG has learned (and relearned) about many problems inherent in each of the possible means of extending HTTP (new methods, new headers, new values or semantics in existing headers). Protocol mechanisms have not been defined to avoid or mitigate all of these possible pitfalls. -It would seem to be a good idea to develop an archival document (FYI, BCP?) to capture some of this knowledge as advise to others who will develop and attempt to deploy HTTP extensions. This will not be a work item of the HTTP working group. After discussion Monday & Wednesday, a new working group (HTTP EXTEND) will be chartered. It is important to move forward on this because there are a large number of working groups that want to layer themselves on top of HTTP. There is a need to develop a document which explains both the "dos" and the "don'ts" of extending HTTP. This document should start with the "don'ts" so they can be captured to prevent future bad practice. The HTTP Extension group will develop PEP, the HTTP extension guidelines document, and the OPTIONS draft. The Extensions team reported a strawman charter for 1) producing an FYI document of guidance on adding features, headers, and methods to HTTP, 2) extending error response codes, 3) and simplifying PEP and OPTIONS into a reliable extension hook. It is NOT an HTTP/1.2 group. Josh Cohen and Scott Lawrence will chair and edit, respectively, an investigation into how-to-extend, not what-to-extend. Other extensions were discussed, e.g., transactional HTTP. People forget about interaction with proxies in general; it should be explicitly considered. The group will also take on Schulzrinne's extend error codes work. (JG thought arguments against on http-wg were really bogus.) A report on experience reading PEP: it was necessary to talk to Henrik to figure it out. A requirements document may be necessary and will be considered. There is no formal requirement for a separate BOF, but the IESG may need to announce the working group. ================================================================ Keith Moore asked for volunteers for a document to integrate TLS & HTTP. Rohit Khare volunteered. ================================================================ Interoperable implementations: To advance to Draft Standard, we need to document at least two independent, interoperable implementations of each feature. It isn't necessary that the features be in the same implementation, and the implementations need not be shipping products. Tuesday night, a half-dozen client, server, and proxy developers sat down with the chair and editor to walk through the draft section by section. The main insight was that we'll need much more systematic support to document the hundreds of requirements in HTTP/1.1. Caching, in particular, seems to be the most fraught with difficulty. Scott Lawrence agreed to continue his (very useful) Thursday testing bees; and there was a survey of interest in face-to-face implementation bake-offs or conference calls. ================================================================ Web Privacy User Services sponsored a BOF on Web Privacy. April Marine reported the broad support for investigating the nexus of trust issues around the Web. A detailed charter awaits debate, though, on web-priv@nasa.gov. A second BOF is projected for LA. ================================================================ Content Negotiation Recipient Feature Profile (nee content-negotiation), weaves together extensibility threads from HTTP, printing, fax, mail, and many other application layer protocols. Ted Hardie reported the conviction the group will set up a registry as quickly as possible. Then, it may tackle aggregation of features and a prototypical example of how to store profiles within LDAP, etc. ================================================================ HTTP-NG W3C has been working on experiments for HTTP-NG, which had a BOF at 39th IETF and will surely be heard from in 1998. ================================================================ CONCLUSION A poll ("Will there be an HTTP/1.2?") had a lot of responses, split 50-50. This was the last planned meeting of the HTTP working group. The group's chartered work is nearly complete, and no further meetings will be necessary. Additional work will happen in other groups or outside a formal working group. The mailing list will remain open. We're not really done: one estimate was that 20 more issues will be raised from the interoperability testing. But regardless, this was the LAST meeting. Scott Lawrence commits to continuing Thursday interoperability tests until such time as testing becomes uninteresting. The HTTP-WG mailing list will remain open indefinitely (or until Standard status 2 years from now).