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

Consider using a proper HTTP implementation #19

Closed
aaugustin opened this issue Apr 6, 2014 · 7 comments
Closed

Consider using a proper HTTP implementation #19

aaugustin opened this issue Apr 6, 2014 · 7 comments

Comments

@aaugustin
Copy link
Member

The HTTP parsing and generation code is very simple at this time.

It could be worth relying on an external library for these parts.

@aaugustin
Copy link
Member Author

@aaugustin
Copy link
Member Author

I'm scaling down my ambitions for this library.

@aaugustin
Copy link
Member Author

Re-opening as I discovered h11, a small pure-Python HTTP parser "sans I/O".

@aaugustin aaugustin reopened this Aug 8, 2016
@aaugustin
Copy link
Member Author

aaugustin commented May 5, 2017

Still unsure what problem this issue actually solves...

@cjerdonek
Copy link
Collaborator

Security maybe?

@aaugustin
Copy link
Member Author

I'm working on replacing the stdlib's MIME parser with a bare-bones custom HTTP implementation. This seemed like the path of least effort.

aaugustin added a commit that referenced this issue Jul 9, 2017
Given that websockets makes straightforward of HTTP, that websocket
implementations can be expected not to exhibit legacy behaviors, and
that RFC 7230 deprecates this behavior, parsing HTTP is doable.

Thanks https://github.com/njsmith/h11 for providing some inspiration,
especially for translating the RFC to regular expressions and figuring
out some edge cases.

I expect the new implementation to be faster, since it has a much
tighter focus than the stdlib's general purpose MIME parser, and
possibly more secure, since it was written from the beginning with
security as a primary goal (with the caveat that it's new code,
which means it's more likely to have security issues).

Fix #19.
aaugustin added a commit that referenced this issue Jul 9, 2017
Given that websockets makes straightforward use of HTTP, that websocket
implementations can be expected not to exhibit legacy behaviors, and
that RFC 7230 deprecates this behavior, parsing HTTP is doable.

Thanks https://github.com/njsmith/h11 for providing some inspiration,
especially for translating the RFC to regular expressions and figuring
out some edge cases.

I expect the new implementation to be faster, since it has a much
tighter focus than the stdlib's general purpose MIME parser, and
possibly more secure, since it was written from the beginning with
security as a primary goal (with the caveat that it's new code,
which means it's more likely to have security issues).

Fix #19.
aaugustin added a commit that referenced this issue Jul 9, 2017
Given that websockets makes straightforward use of HTTP, that websocket
implementations can be expected not to exhibit legacy behaviors, and
that RFC 7230 deprecates this behavior, parsing HTTP is doable.

Thanks https://github.com/njsmith/h11 for providing some inspiration,
especially for translating the RFC to regular expressions and figuring
out some edge cases.

I expect the new implementation to be faster, since it has a much
tighter focus than the stdlib's general purpose MIME parser, and
possibly more secure, since it was written from the beginning with
security as a primary goal (with the caveat that it's new code,
which means it's more likely to have security issues).

Fix #19.
aaugustin added a commit that referenced this issue Jul 9, 2017
Given that websockets makes straightforward use of HTTP, that websocket
implementations can be expected not to exhibit legacy behaviors, and
that RFC 7230 deprecates this behavior, parsing HTTP is doable.

Thanks https://github.com/njsmith/h11 for providing some inspiration,
especially for translating the RFC to regular expressions and figuring
out some edge cases.

I expect the new implementation to be faster, since it has a much
tighter focus than the stdlib's general purpose MIME parser, and
possibly more secure, since it was written from the beginning with
security as a primary goal (with the caveat that it's new code,
which means it's more likely to have security issues).

Fix #19.
aaugustin added a commit that referenced this issue Jul 9, 2017
Given that websockets makes straightforward use of HTTP, that websocket
implementations can be expected not to exhibit legacy behaviors, and
that RFC 7230 deprecates this behavior, parsing HTTP is doable.

Thanks https://github.com/njsmith/h11 for providing some inspiration,
especially for translating the RFC to regular expressions and figuring
out some edge cases.

I expect the new implementation to be faster, since it has a much
tighter focus than the stdlib's general purpose MIME parser, and
possibly more secure, since it was written from the beginning with
security as a primary goal (with the caveat that it's new code,
which means it's more likely to have security issues).

Fix #19.
aaugustin added a commit that referenced this issue Jul 17, 2017
Given that websockets makes straightforward use of HTTP, that websocket
implementations can be expected not to exhibit legacy behaviors, and
that RFC 7230 deprecates this behavior, parsing HTTP is doable.

Thanks https://github.com/njsmith/h11 for providing some inspiration,
especially for translating the RFC to regular expressions and figuring
out some edge cases.

I expect the new implementation to be faster, since it has a much
tighter focus than the stdlib's general purpose MIME parser, and
possibly more secure, since it was written from the beginning with
security as a primary goal (with the caveat that it's new code,
which means it's more likely to have security issues).

Fix #19.
@aaugustin
Copy link
Member Author

Another reason for not relying on a full HTTP implementation: https://tools.ietf.org/html/rfc6455#section-1.7:

The WebSocket Protocol is an independent TCP-based protocol. Its
only relationship to HTTP is that its handshake is interpreted by
HTTP servers as an Upgrade request.

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

2 participants