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

On recoverable protocol errors from real-world usage. #96

Closed
tomchristie opened this issue Jan 16, 2020 · 1 comment
Closed

On recoverable protocol errors from real-world usage. #96

tomchristie opened this issue Jan 16, 2020 · 1 comment

Comments

@tomchristie
Copy link
Contributor

Figured I'd raise this based on some useful real world feedback in encode/httpx#767 which includes a bunch of cases that urllib3 deals with, but h11 (correctly) identifies as protocol errors.

There's four seperate classes of protocol errors mentioned in that ticket...

  1. Multiple Content-Length headers. (Already covered by Handle multiple Content-Length headers with the same value #92)
  2. Status code outside of valid range. (Returned a "600")
  3. "malformed data" - I believe triggered by a Server: header with no value.
  4. "Receive buffer too long" - Presumably an oversized header or similar but cause wasn't immediately clear.

I'm wondering if you've any thoughts on what (if anything) we might usefully do to have h11 be able to be lenient to some of these protocol errors?

Purely based on the feedback in that particular ticket, and given that #92 already covers one of the cases...

  • Would it be reasonable to be lenient to invalid status code ranges?
  • Would it be reasonable to switch the header regex to allow empty values even tho not strictly valid?
@tomchristie
Copy link
Contributor Author

Apologies, I just noticed that #95 was already filed here.

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

No branches or pull requests

1 participant