chansen
New RFCs update HTTP/1.1
I saw this page summarizing some changes: http://evertpot.com/http-11-updated/
We need to review changes and double check how we hold up with the new RFC.
The one that jumps out that we're out of spec is this one:
The status codes 301 and 302 have been changed to allow user agents to rewrite the method from POST to GET. This is a good example of a case where everybody has been (incorrectly) already doing this, and the spec now reflects the real world implementation.
Also, 7230 has this:
"Userinfo (i.e., username and password) are now disallowed in HTTP and HTTPS URIs, because of security issues related to their transmission on the wire. (Section 2.7.1)"
Doe that mean _split_url() should remove support for user:pass@host?
The spec says that you can't transmit username/password in a URI over the wire, which I don't think we do. It doesn't prohibit using that format for someone to make a request, though.
Ah I see, that makes sense. I just wasn't sure how the full URI would ever end up on the wire. Surely it always get divided up to become the path, and host and authorisation headers?
I think so, but maybe there's some obscure header that wants the original URI or something. Or maybe it's just a general precaution statement.
Links to summaries of changes, with selected items that seem relevant to HTTP::Tiny (i.e. clients) given as a checklist:
- [x] stricter header field/value rules
- [ ] single digit protocol version:
HTTP-name "/" DIGIT "." DIGIT - [ ] The NUL octet is no longer allowed in comment and quoted-string text
- [ ] Bogus Content-Length header fields are now required to be handled as errors by recipients (IIRC, we already do this)
- [ ] The algorithm for determining the message body length has been clarified to indicate all of the special cases
- [ ] Chunk length does not include the count of the octets in the chunk header and trailer. Line folding in chunk extensions is disallowed.
- [ ] An idempotent sequence of requests is no longer required to be retried.
- [ ] GET can have a body (we may actually already allow this by accident)
- [ ] Content-Range has been explicitly banned in PUT requests
- [ ] Rules for safe redirects and method change (PUT->GET) have changed. See 7231#6.4
- [ ] Allow has been reclassified as a response header field
No changes
No changes
No changes
No changes
Extra for your todo list: Location: can now be relative (7231#7.1.2).
Update: My mistake. I was crashing out in _split_url, saw the regex and didn't look deeper. If I had I would have discovered that our code is trying to deal with Location: itself, and not handling relative URLs.
