Reject non-HTTP schemes in StreamHandler #2989
Conversation
If an URI that does not use the HTTP stream wrapper is passed to the StreamHandler then the magic `$http_response_header` variable will not be filled, thus remaining `null`. This ultimately results in a `TypeError`, because `null` is passed to HeaderProcessor::parseHeaders(), which expects an `array`.
Non-HTTP schemes are effectively not supported, because the HTTP response headers will only be filled for the `http` and `https` stream wrappers. Also Guzzle is an HTTP client after all. Reject non-HTTP schemes early on to improve error messages and to prevent possible exploits using odd stream wrappers in case an non-fully-trusted URL is passed to Guzzle.
TimWolla
force-pushed
the
stream-non-http
branch
from
353739c
to
d198940
Compare
|
What if you want to fetch a file on an FTP server. Then you cannot use the stream handler, right? |
|
Maybe something to consider for Guzzle 8. I don't feel like we can merge this on Guzzle 7. |
Right, but you already cannot do this, because FTP is not HTTP and thus no HTTP headers will be set. In fact FTP is how I originally found out about this issue: https://www.woltlab.com/community/thread/294643-jeden-tag-selben-fehler-im-log/ (in German). So this does not break anything that wasn't broken previously. It just improves the error message. |
|
Alternatively just take the first commit for now, I've intentionally split this into two separate commits. The first one fixes the underlying issue (and that should be easy to verify). |
That's where I disagree. For my / our projects I rather prefer separate small commits (unless they are useless stuff like “fix typo”). But you're the maintainers and need to work with it, so I won't complain 😃 |
|
Most people (myself included) don’t do nice commit messages like you show here. I agree that those are pretty and they do make sense. Especially if we also force the PR to be updated with the latest from master before we merge.
But that is not a good general rule enforce. (Not for an open source project at least) :/
And I rather have just one solution for everything.
… On 13 Mar 2022, at 17:29, Tim Düsterhus ***@***.***> wrote:
I do need to squash the commits though. I like a nice history like this:
That's where I disagree. For my / our projects I rather prefer separate small commits (unless they are useless stuff like “fix typo”). But you're the maintainers and need to work with it, so I won't complain 😃
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you modified the open/close state.
|
I recommend not to squash this PR when merging, as the commits try to tell a story.
Detailed reasoning can be found in the commit message of each of the both commits.