Skip to content

http_fopen_wrapper.c: Handle HTTP 101 #6730

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

Closed
wants to merge 1 commit into from

Conversation

manuelm
Copy link
Contributor

@manuelm manuelm commented Feb 25, 2021

Don't wait for further responses after a HTTP 101 (Switching Protocols) response

@nikic nikic requested a review from cmb69 March 1, 2021 10:19
cmb69
cmb69 previously requested changes Mar 1, 2021
Copy link
Member

@cmb69 cmb69 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the PR, but the solution doesn't look right. I assume that you're facing the issue that there is no following HTTP/1 status line, so all headers will be skipped. Instead looking for that HTTP/1, we should be looking for an empty line which terminates the 1xx response, and try to get the response status from the following line. It seems to me the current code for handling 101 is a bug, so a PR may target PHP-7.4.

There should also be a mechanism to get the actual headers of 101 responses (maybe 1xx in general?) I'm not sure which mechanism, though.

@manuelm
Copy link
Contributor Author

manuelm commented Mar 1, 2021

There should also be a mechanism to get the actual headers of 101 responses (maybe 1xx in general?) I'm not sure which mechanism, though.

I wanted to fetch the headers from the 101 response, because that's what I'm interested in. Everything after the 101 response + headers is protocol specific and shouldn't be handled by PHP imho. With this patch it was easily possible to implement a WebSocket handler on top of Guzzle.

It seems to me the current code for handling 101 is a bug, so a PR may target PHP-7.4.

Actually that was my intention but I somehow messed up.

Thanks for the PR, but the solution doesn't look right.

Imho this condition should solely check for HTTP 100-continue but that might break things

@manuelm manuelm changed the base branch from master to PHP-7.4 March 1, 2021 13:56
@cmb69
Copy link
Member

cmb69 commented Mar 1, 2021

Thanks for the clarification!

Imho this condition should solely check for HTTP 100-continue but that might break things

Yes, that's why I suggested to implement some mechanism to be able to get the headers of such requests. Maybe something like follow_location; if that was enabled by default, no BC break would be introduced.

Anyhow, I don't think that we actually break anything in practice with your patch (in theory maybe upgrade requests from HTTP/1.0 to HTTP/1.1, but 1xx responses are not supposed to be sent to HTTP/1.0 clients anyway). But I'm not sure.

Could you please file a respective bug ticket for easier reference. And, if possible, adding a test case would be great as well.

@cmb69 cmb69 dismissed their stale review March 1, 2021 14:03

The change might be okay as workaround.

@manuelm
Copy link
Contributor Author

manuelm commented Mar 1, 2021

Yes, that's why I suggested to implement some mechanism to be able to get the headers of such requests. Maybe something like follow_location; if that was enabled by default, no BC break would be introduced.

Adding a new stream context option should be do-able. Something like return_informational (or return_http1xx)?

Could you please file a respective bug ticket for easier reference. And, if possible, adding a test case would be great as well.

Sure

@cmb69
Copy link
Member

cmb69 commented Mar 1, 2021

Adding a new stream context option should be do-able. Something like return_informational (or return_http1xx)?

Something like this, or maybe the other way round, e.g. ignore_informational. Might be worth a discussion (attempt) on the internals mailing list.

Don't wait for further responses after a HTTP 101 (Switching Protocols) response
@manuelm
Copy link
Contributor Author

manuelm commented Mar 6, 2021

I've added the requested bug report and a unit test.

@cmb69
Copy link
Member

cmb69 commented Mar 8, 2021

Thank you!

@php-pulls php-pulls closed this in 5787f91 Mar 8, 2021
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

Successfully merging this pull request may close these issues.

2 participants