Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

New RFCs update HTTP/1.1 #42

Open
dagolden opened this issue Jun 11, 2014 · 7 comments
Open

New RFCs update HTTP/1.1 #42

dagolden opened this issue Jun 11, 2014 · 7 comments

Comments

@dagolden
Copy link

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
Copy link
Contributor

JRaspass commented Sep 8, 2014

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?

@dagolden
Copy link
Author

dagolden commented Sep 8, 2014

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
Copy link
Contributor

JRaspass commented Sep 9, 2014

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?

@dagolden
Copy link
Author

dagolden commented Sep 9, 2014

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
Copy link
Contributor

JRaspass commented Sep 9, 2014

Fair enough.

@xdg
Copy link
Collaborator

xdg commented Apr 17, 2016

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
Copy link

robn commented Dec 7, 2016

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants