During implementaton of the HTTP/1.1 Proposed Standard, a number of issues were raised that needed to be addressed before the HTTP/1.1 is moved to Draft Standard (the next phase of the IETF standardization process). The issues were resolved in a number of different ways, depending upon the severity of the problem and how it interacted with IETF process. The following is a list of the issues raised before last call of the documents for draft standard, and the solutions.
The comments are based on the HTTP/1.1 Proposed Standard (RFC 2068).
When referring to issues on the list, it helps the editor if you put the issue name into the subject line of any mail messages.
The list below also needs to be organized into some sort of priority list. You can presume, though, that if an ID is associated with an issue, it is relatively important (but the lack of an ID does not mean that the issue is unimportant).
The No field contains an arbitrary number of the issue, which is guaranteed to change in the future (i.e. use the Name of the issue, not its number, in any discussions; it is for convenience during teleconferences.)
The Name field contains the name of the issue; and there are hypertext anchors present in this document of these names for each issue, to aid in cross referencing. We generally don't change the name or delete it once an issue has been opened.
The Short Description field contains a short description of the issue, often hyperlinked to a longer explanation of the issue.
The Status field can have the following values:
The Raised By field contains a mailto: link to the name of the person who raised the issue initially.
The Resp. field contains a mailto: link to the name of the person responsible for drafting language to fix the issue, or responsible to see that action on the issue occurs.
4 Authorization Technical issues closed since Auth-00: DIGEST-MESS, AUTH-INFO-SYNTAX, DIGEST-PROBS, DIGEST-SCALING
3 Technical issues closed since Rev-02: IF-PRECEDENCE, CONTENT-LENGTH, 409-CONFLICT
11 Editorial issues closed since Rev-02 (all edited into Rev-03): UNIMPLEMENTED, IDENTITY_TE, IM_IUS_412, HEAD_WITH_IMS, 304-SHOULD, KRISTOL-02, PUT-ENTITY-HEADERS, LOCATION-PUT, ETAG-CLARITY, 204-UNCLEAR, CACHE-CONDITIONAL
9 Technical issues closed since Rev-01:
PUT-RANGE, MULTIPART, CONTENT-ENCODING, CONTENT-LENGTH, CONTENT-BASE, MULTIPLE-CONTENT-LOCATION, IPV6-ADDR-URLS, DIGEST-SCALING
21 Editorial issues closed since Rev-01 (all edited into Rev-02):
EXPECTATION, TRANSPARENT-PROXY, CHARSET-NIT,TYPO-NITS, CASE-DATE, UPDATE_ACKS,
REQUIREMENTS, LINE-LENGTH, IDENTITY-TE,
SEC-CACHING, DS-INTERNIC, REORDER, PATTERSON, IN-THEORY, DISPOSITION, EXPECT-AMBIGUITY, CHANGES-2068, REQUEST_TARGET, RONALD, SEC-ORDER, IANA_DIRECTIONS,
|A1||DIGEST-MESS||In Auth-01||Digest authentication has a number of problems, but we gotta get passwords in the clear off the wire.||
Goal: no password in the clear; message integrity is gravy if possible, but
not the meat.
Larry and Paul to prepare draft from John's diffs.
|A2||DIGEST-SCALING||Subsumed by DIGEST-MESS||Can digest be used for cross server authentication?||
|In Auth-01||Authentication-Info lacking extension field||Contained in description||
|A4||DIGEST-PROBS||In Auth-01||Dave Krystol has found some problems||Solution one problem||dmk|
|Proposal to add a new s-maxage directive to deal with overlooked cache case. (Mailing List discussion)||Jeff issued new draft.||mogul||mogul|
Not yet in Auth-01
|The indexes need cleanup.||jg||jg|
|A7||XREFS||Open||Make sure authentication draft cross references correct section in HTTP spec.||Just do it!||jg||
|-1||IF-PRECEDENCE||In Rev-03||What is the right precedence between If headers?||In message, though Roy's point about "undefined" is well taken.||mogul||mogul|
|What does 409 really do?||Paul was confused; can't think of any better wording though.||paulle||mogul|
|Confusion on Content-Length||Reclassified from editorial. Resolution. Comments fix in 03.||john||mogul|
|2||MULTIPART||In Rev-02||Should the HTTP spec define interactions with multipart?||Proxies should not be examining multipart for HTTP headers etc. Proposal from Roy||jpalme||fielding|
HTTP allow more than one Content-Location
in the same message heading?
|Too late to change HTTP/1.1; the MHTML group is looking at other Alternatives.||jpalme|
|4||CONTENT-BASE||In Rev-02||RFC2068 wording was not absolutely clear that Content-Base was required||Deleted and notes as to why added to changes to RFC2068 section; also reference MHTML spec.||lawrence|
|5||IPV6-ADDR-URLS||Closed||Proposals for URL syntax for IP/V6 addresses have problems||Not HTTP's problem.||mogul|
|There are problems in the Content-Encoding specification||Proposed Resolution Comments, Koen. Solution is to add a note not to use ;q on x-gzip and x-compress. Also interacts with TRAILER_FIELDS.||mogul||frystyk|
|7||OPTIONS||In Rev-01||Options insufficiently defined. Discussion has not converged on enhanced Options. Internet Draft with proposal.||
Undock and follow up in extensions working group.
Rev-01 has minimal fix to base spec.
Draft was In Rev-00
Removed in Rev-01
Text to clarify
305 in Rev01 and In Rev-02
redirect (305) is at least vague, but more likely broken.Working
Josh sent draft; draft required fancy OPTIONS proposal, and 306 has serious security problems.
|305 should be limited to use by origin servers, to a single request, to a proxy. Working group opinion: set proxy functionality is important, but at this date we will undock it and proceed independently. Deprecate broken 305 interpretation more forcefully.||josh||josh, luotonen|
Removed from Rev-02
Security considerations in Rev-02.
|Should there be a revalidate requested code?Comments from JG, many others.Updated proposal from Paul Leach.||This is believed to be a REAL PROBLEM, that needs to be fixed. Working group decision is that this issue should be undocked and dealt within new HTTP extensions group, and likely handle more than this solution does.||kdyer||paulle|
|In Rev-01||Should range requests apply before or after content coding?||Revised proposal; also involves TRAILER_FIELDS||mogul||frystyk|
|11||TRAILER_FIELDS||In Rev-01||What fields can go into headers and/or trailers||Should we introduce a mechanism for the client to say that it accepts trailers? Henrik's updated proposal.||frystyk|
Removed from Rev-02.
|Do Content-Range and PUT work together?||
out from Paul Leach.
No consensus; removed.
|13||DIGEST_SYNTAX||In Auth-00||Syntax errors in Digest specification||cleanups.||
|In Auth-00||What should the protection space be for basic?||Allow same or lower path.||franks||macrides|
|15||CONTRADICTION||In Rev-01||PROXY-LENGTH change introduced an error.||PROXY-LENGTH change introduced an error. Comments from Paul Leach (simpler proposal) adopted.||koen|
|In Rev-01||What to do if If-Modified-Since and etags INF doesn't match.||Jeff supplied a fix.||henrysa||frystyk|
|In Rev-01||What happens when sending some invalid byteranges?||Idea is not to be smart but to reply to what the client asked for||mogul|
|18||RE-VERSION||In Rev-01||The assumption that the HTTP Version number is hop-by-hop may not be true in practice.||
Need stronger requirements on proxies. Clarification
and words to close the issue. Still
some comments and confusion.
Henry Sanders to document the discussions at Munich and Washington.
|19||HOST||In Rev-01||Where/when should the host part of a URL be interpreted if not fully qualified?||Further discussion. Proxy can add but not change it if it is already there.||dahming||jg|
Proceed as ID
|Connect method needs documenting (used by SSL)||Add reference to the document; editorial issue to document.||luotonen||frystyk|
|21||FORCE_PROXY||Subsumed by PROXY-MAXAGE||What happened to this? Forcing HTTP/1.1 proxies to revalidate responses.||editors|
|22||NO_CLOCK||In Rev-00||Draft from Scott Lawrence||editors|
|23||301-302||In Rev-01||Problems with redirecting requests||Active discussion on list. Consensus at Munich IETF seemed to be to swap the codes, rather than making the protocol cruftier. Was reverted after Munichto the following wordings and perform a last call||yarong|
|24||REDIRECTS||In Rev-01||How many redirects should be allowed, required?||
Discussion open; Roy's
|25||LINK_HEADER||In Rev-00||Conflict between HTML and HTTP regarding interpretation of Link header||Delete the Link header from appendix; solved by editorial issue REMOVE_19.6|
|Should we add a note explaining how CGI can be cached?||
Mail with closure
Roy's mail with dissent.
Roy's position adopted
|Problems with caching headers in Warnings||
Klause Weide comments.
Jeff updated fix.
|In Rev-01||Date string used in the If-modified-since header.||Proposed resolution. Should we put a note into a bug compatibility section? Adopt Koen's solution||luotonen||jg|
|29||403VS404||In Rev-01||Current wording says: Description for "404 Not found" says "403 Forbidden" can be used instead. As Ari Luotonen points out - this should be the other way round.||Henrik's fix adopted||luotonen||frystyk|
|In Rev-01||Conservative vs. Optimistic Age calculation, and clarification. Roy sent out an Internet Draft; Jeff also sent a draft in.||Adopt Roy's draft, in preference to Jeff's; don't adopt Koen's further suggestion. (synchronized clock wording already present in 13.2.3)||fielding||jg / mogul|
|31||AUTH-CHUNKED||In Rev-00||Chunked vs. Digest problem||Fix.||lawrence||
|32||REQUIRE-DIGEST||In Auth-00||There needs to be some way to require that Digest authentication is used. ID has been issued||The ID contains resolution; John Franks has comments.||lawrence||paulle|
Retry-After apply to:
- 3xx Redirect class responses
- as well as 503 Service Unavailable
|Bob believes it can apply to all 3xx responses, and that a minor change to clarify it can be sent is enough.||briscoe||jg|
|34||VARY||In Rev-01||Vary is really cache advice. The description varies throughout the spec||Henrik's fix||frystyk||frystyk / fielding|
|In Rev-00||When should Proxy-Authorization header be sent?||Dave Kristol's suggested editorial clarification; but probably not needed as it is part of credentials. Clarification in section 11. Henrik'sfix||dmk||frystyk|
|Proxies should be able to add Content Length.||We need a group of headers which proxies can add but not modify. This is also the case for content-encoding||dan||paulle|
|37||LANGUAGE-TAG||In Rev-00||Language tag matching needs to be added||Resolution||gjw||masinter|
|38||TSPECIALS||In Rev-00||Conflicting definitions of syntax production 'tspecials' in RFC 2045 and RFC 2068||Rename t-specials so that we avoid conflicts||klyne|
|39||STATUS100||In Rev-00||Message transmission requirements may need clarification.||Resolution.||rlgray||mogul|
|40||QZERO||In Rev-00||Quality = 0.0 should mean "not acceptable"||Fold into 1.1 spec||gjw||koen|
|41||RANGE-ERROR||In Rev-01||What should be the correct server response for a byte range that is outside the actual contents of the file?||
416 error with content range showing the total content length.
John Franks found problem; Jeff redrafted.
|In Rev-00||Cache-Control: No-cache needs clarification. (Jeff's mail)||This is question of clarifying - not changing contents and fix the BNF error||abaird||mogul|
|43||COMMENT||In Rev-00||Quoting confusion||Adopt Roy's clarification.||ulrich||masinter|
|In Rev-00||Content-Location needs minor clarification||C-L may be useful in PUT and DELETE. Henrik's fix||kweide||frystyk|
|In Rev-00||Backslash within quotes||Should be allowed but with a note in compatibility section (xref). Does this impact other headers as well? Comments stay the way the they are. Fix||Ulrichl|
|46||CACHE-CONTRA||In Rev-00||Apparent contradiction between 14.8 and 14.9.4||Resolution plus Internet draft||koen|
|In Rev-00||Need to either define field-name or change grammar||Solution||abaird|
|48||BYTE-RANGE||In Rev-00||Is the right meta-data returned on range requests?||Fix||frystyk||frystyk|
|49||LWS-DELIMITER||In Rev-00||Implied LWS rule does not talk about LWS as delimiter between tokens, but as some 1.1 headers use LWS instead of tspecials as delimiters between tokens||Fold into 1.1 spec.||koen||koen|
|50||CRLF||In Rev-00||Is a CRLF in a quoted-string legal, and what is the relation to header continuation?||Should be allowed but deserves a note in the backwards compatibility appendix saying that this may break existing implementations||Kristol|
|51||MAX-AGE||In Rev-00||Max-age in responses not defined||Additional Notes for inclusion in proposed resolution (Roy sez OK)||fielding|
|52||100DATE||In Rev-00||Should Date be part of a 100/101 response?||Fold into 1.1 spec. Adopt Lawrence's draft with changes from Jeff Mogul||lawrence||mogul|
|53||DISPOSITION||In Rev-00||Should content-disposition from RFC 1806 be considered for HTTP? The same goes for content-description (a.k.a. Title).||Add to Appendix||masinter||koen|
|54||CHUNKED||In Rev-00||Chunked encoding clarification||Editorial - clarify the wording||rlgray||jg|
|55||CACHING||In Rev-00||Criticism of HTTP/1.1 caching and paper||13.1.1 needs editorial change.||dingle||jg|
|In Rev-00||Please clarify * is legal in HTTP1/1 Accept-Charset Header.||Fold Internet Draft into 1.1 spec.||ftang|
|58||PADDING||In Rev-00||Should padding rules be loosened in chunked encoding?||Fold into 1.1 spec. Leading 0's are OK.||john||lawrence|
|59||CONNECTION||In Rev-00||Should spec be clarified around connection:Cache-Control?||Jeff Mogul's suggested resolution||urbani|
|60||RANGES||In Rev-00||206 response should allow to range request without knowing total content length||Fix||frystyk||frystyk|
|61||WARNING-8859||In Rev-00||Warnings, and the use of 8859||1522 has been obsoleted - reference 2047||mduerst||jg|
|62||SHOULD-8859||In Rev-00||Charset confusion confusion||Backwards compatibility appendix with collection of notes instead of throughout the spec||misha||jg|
|63||X-BYTERANGES||In Rev-00||Need note about x-byteranges in spec.||Worth a note in compatibility mode appendix||akosut||jg|
|In Rev-00||What are the nesting rules (e.g. chunk and compress)||We need wording just like content-encoding, see section 14.12||jg|
|Is there any problem in HTTP/1.1 causing fin-wait-2 problems, or is this strictly a implementation bug (client, server, or TCP stack)?||Implementation bug. There are work arounds and it could be rolled into the connection draft? Roy has some notes on this||fielding||jg|
|Should 304 include Last Modified?||No change required||frystyk|
|Currently the spec says that encoding is part of content negotiation. This is not the case as it is for the sender to determine.||Leave it as is.||mogul||mogul|
|68||VERSION||RFC 2145||What version number should HTTP/1.1 servers return? (Internet Draft) (Mailing list discussion) (more discussion)||IESG action completed; See PROXY_FORWARD. Editorial note: reference added in Rev-00.||jcma||mogul|
|69||HIT-METER||RFC 2227||Hit metering is RFC 2227||RFC 2227|
|70||SAFE||Move forward as experimental? Koen is reparing a RFC||SAFE proposal not in charter||No action to be taken; too much already on working group plate.||macrides|
|71||UAHINT||Move forward as experimental?||UAHINT proposal not in charter||No action to be taken; too much already on working group plate.||macrides|
|Out of scope for HTTP/1.1||draft-harada-http-xconn-from-01||independent document.||mogul|
|73||COOKIE||Out of scope for HTTP/1.1||Compatibility problem of RFC 2109||Draft should proceed independently.||dmk|
|74||PROXY-AUTH||Out of scope for HTTP/1.1||Proposal of Josh Cohen to modify Proxy authentication.||Reject proposal due to compatiblity problems.||josh|
|75||CLOSE||Out of scope for HTTP/1.1||
should close the connection?
(Internet Draft) (Mailing List discussion)
|Draft should proceed independently.||briscoe||jg|
Subsumed by AGE
|Should age be touched if a document is never resident in a cache? Internet draft|
Subsumed by CONTENT
|Confusion about accept-encoding language||See also ENCODING-NOT-CONNEG||koen|
|69||IDENTITY_TE||In Rev-03||The "identity" transfer-coding is used only in the TE header, and SHOULD NOT be used in the Transfer-Encoding header.||In message||mogul||mogul|
|70||IM_IUS_412||In Rev-03||Seek clarification on conditional hdrs||In message||dmk||mogul|
it "legal" to send an
If-Modified-Since header with a HEAD method?
|72||304-SHOULD||In Rev-03||If-Modified can always be ignored by returning an entity.||MUST becomes a SHOULD||henrysa||jg|
|In Rev-03||The entity headers, in addition to the entity body, should be associated with the request URI for PUT.||In message||paulle||paulle|
|74||LOCATION-PUT||In Rev-03||How should Content-Location be interpreted with Put?||In message.||paulle||paulle|
|75||ETAG-CLARITY||In Rev-03||Etag needs clarification||In message.||mogul||mogul|
|76||204-UNCLEAR||In Rev-03||Unclear about updating meta information||In message.||paulle||paulle|
|In Rev-03||Dave has found some more...||Jeff's response.||dmk||jg|
|78||KRISTOL-02||In Rev-03||Dave has done another read....||Caching||dmk||jg|
|79||EXPECTATION||In Rev-02||Expectation MUST or SHOULD?||In message.||lawrence||lawrence|
Removed from Rev-03
|Not clear that not-implemented error must be implemented. Comments||Roy is right.||lawrence||lawrence|
|In Rev-02||Should be distinction for transparent proxies vs. non-transparent||Roy drafted language||lawrence||fielding|
|82||CHARSET-NIT||In Rev-02||Nit in Accept-Charset.||Remove sentence||howard||jg|
|83||CASE-DATE||In Rev-02||Case sensitive date format.||Roy's original wording.||fielding||jg|
|84||TYPO-NITS||In Rev-02||Spell check, look for dups, extra/missing characters, look at references. etc.||Just do it.||jg||jg|
|85||WORD-LOSTIT||Open||Word lost my links to the issues list.||May ignore this problem.||jg||jg|
|86||DS-INTERNIC||In Rev-02||Hyperlinks to ds.internic.net need fixing (to IETF.org).||Just do it.||jg||jg|
|87||IDENTITY-TE||Closed||The "identity" transfer-coding is used only in the TE header, and SHOULD NOT be used in the Transfer-Encoding header.||Contained in report. Not accepted, except for the missing word in the report, as text already says this.||mogul||jg|
|88||LINE-LENGTH||In Rev-02||Line length rules for MIME should be referenced.||Reference MIME spec as warning to HTTP implem. that may share code with MHTML.||Nick_Shelness||jg|
|In Rev-02||MHTML and HTTP spec's differ for Content-Location. Also see MULTIPART.||Several possible. Lets see the MULTIPART solution before deciding.||Nick_Shelness||jg|
|90||SEC-CACHING||In Rev-02||Should be security/privacy considerations around caching. Secure the system, MITM, trust.||Will draft and forward to list.||masinter||jg|
|91||REORDER||In Rev-02||Reorder sections of HTTP/1.1||Just do it. Will be in Rev-02||jg||jg|
|92||IN-THEORY||In Rev-02||Normative SHOULD after "In theory" clause...||Accept suggested correction.||mogul||jg|
|94||RONALD||In Rev-02||Nits in 307, and examples in new materials.||Accept suggested corrections||Ronald.Tschalaer||jg|
|95||SEC-ORDER||In Rev-02||Security Considerations section needs reordering to improve flow.||Just do it.||jg||jg|
|96||PATTERSON||In Rev-02||Editoral nits against rev-01.||Fixes in this message, and this one.||Ross_Patterson||jg|
|In Rev-02||The Expect mechanism does not state whether token-matching should be case sensitive.||Accept suggested correction.||mogul||jg|
|98||CHANGES-2068||In Rev-02||Process requires a changes from previous RFC section.||Added by jg.||
|100||DISPOSITION||In Rev-02||Content-Disposition could use some TLC||Clarified that filename is the only part used, and removed ref. to content-octet-stream||kweide||jg|
|In Rev-02||Will need section to help Postel's people out (e.g. transfer coding)||Just do it!||jg||jg|
Removed from Rev-02
|Document should refer to status code registry.||
to Schultzrinne, spec currently limits codes to 3 digits.
No concensus on registry.
|Closed||Should request-URI become Request-Target?||Refused: Too sweeping a terminology change for this late date.||fielding|
|106||REQUIREMENTS||Closed||Need table of requirements like RFC 1122 and 1123; Jeff issued a more extensive example Sample was in Rev-00 Sample removed Rev-01||Volunteers haven't stepped forward.||all||jg|
|In Rev-01||The descriptions of Content-Length in rev-00 are slightly out of sync.||frystyk||jg|
|In Rev-01||Nit in text of generic message||Make text consistent with BNF||deanj||jg|
|109||UPDATE_ACKS||In Rev-01||Acknowledgements need updating||Any further ones please send mail!||jg||jg|
|In Rev-01||Jim Whitehead pointed out an inconsistancy between MAY and SHOULD in section 14.36.2; range requests are optional.||SHOULD becomes should||ejw||jg|
|111||EBNF||In Rev-01||The EBNF in draft-ietf-http-v11-spec-08.txt has been checked for formal syntax and context errors.||js||jg|
|112||CODES||In Rev-01||New response codes should be contiguous with old ones.||make them so.||jg||jg|
|113||CLEANUP||In Rev-01||Clean up Microsoft Word document to make generating HTML easier.||rbriscoe||jg|
RFC for UTF-8 has issued.
HTTP/1.1 should refer to rfc 2130,
and to IETF policy draft-alvestrand-charset-policy-xx.txt
|Need ref to policy statement.||jg|
|Language around strong and weak validators talks about validators.||No response from gjw asking for clarification.||gjw||jg|
dock Digest authentication?
Change section 2.1.3 that the AuthenticationInfo
Header is allowed in the footer of a chunked encoded HTTP message.
|Change to allow AuthenticationInfo Header in the footer of a chunked encoded HTTP message. Move basic into Digest and keep as separate document.||masinter||jg|
|117||URL-SYNTAX||In Rev-01||Use the revised URL syntax draft rather than repeating this in HTTP. Make sure that this says the same thing as currently described in the HTTP spec.||New spec has issued by Roy and Larry.||masinter||
|118||1310_CACHE||In Rev-01||Clarify section 13.10 and make requirements explicit||
Comments from dwm
|Clarify when message bodies are sent||
Morris has had comments.
Roy and Jeff's fix.
|120||BNFNAME||In Rev-00||BNF name is misleading.||dmk||jg|
Accept-Ranges be listed in section 6.2 as a response header?
|122||KEEP-ALIVE||In Rev-00||Persist connection token referred to||tromly||jg|
|123||KEYWORDS||In Rev-00||Spec should use Bradner's terms, and ref. them.||jg||jg|
|In Rev-00||Refer to the version rfc 2145 in HTTP/1.1 spec||Reference to RFC 2145 should be folded into the spec.||masinter||jg|
|125||XREF||In Rev-00||Nit in cross reference||conings||jg|
|In Rev-00||Spec should probably reference RFC 2076, "common internet mail headers"||jg||jg|
|127||NO-CACHE||In Rev-00||We did not intend the "in that case"||abaird||jg|
|128||FIX-REF||In Rev-00||Fix reference to persistent connections work||touch||jg|
|In Rev-00||Clarify distinction between origin and proxy server persistent connection requirements.||bertold||jg|
|130||CONNECTION2||In Rev-00||Make implied connection requirement explicit.||mogul||jg|
|131||GMT-UTC||In Rev-00||GMT may not always be UTC||Proposed resolution||mogul||mogul|
|In Rev-00||Clarify last sentence of 7.1 to say "MUST be forwarded by proxies"||jg||jg|
|133||REFERER-SEC||In Rev-00||Add some security considerations regarding Referer header field||koen||jg|
|134||CHUNK-EXT||In Rev-00||Add sentence about chunk-ext to section 3.6||jg|
|The contents is historical at best and should be removed||Various historical material now in RFC 2068 has been removed.||jg|
|136||IDEMPOTENT||In Rev-00||9.1.2 Idempotent Methods is basically wrong||Proposed resolution||mogul|
|137||REF-SIGCOMM||In Rev-00||Reference upcoming Nielsen et. al. Sigcomm paper.||jg|
|138||1521-OBSOLETE||In Rev-00||RFC 1521 has been obsoleted by 2045.||Replace all references.||jg|