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.

[JRaspass]

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.

[JRaspass]

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.

[JRaspass]

Fair enough.

[xdg]

Links to summaries of changes, with selected items that seem relevant to HTTP::Tiny (i.e. clients) given as a checklist:

RFC 7230 - Changes from 2616

• 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.

RFC 7231 - Changes from 2616

• 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

RFC 7232 - Changes from 2616

No changes

RFC 7233 - Changes from 2616

No changes

RFC 7234 - Changes from 2616

No changes

RFC 7235 - Changes from 2616

No changes

[robn]

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.