[wp-trac] [WordPress Trac] #36280: HTTP API (Streams backend) secured proxy tunnels and chunked and zlib on the fly streaming
noreply at wordpress.org
Mon Mar 21 04:12:31 UTC 2016
#36280: HTTP API (Streams backend) secured proxy tunnels and chunked and zlib on
the fly streaming
Reporter: bobbywalters | Owner:
Type: defect (bug) | Status: new
Priority: normal | Milestone: Awaiting Review
Component: HTTP API | Version: trunk
Severity: normal | Resolution:
Keywords: | Focuses:
Comment (by bobbywalters):
Replying to [comment:1 dd32]:
> Two initial things that stand out:
> > Using the PHP builtin stream filter 'dechunk'
> That's available in PHP 5.3 and later, as we're still supporting PHP 5.2
that should have a feature check first.
> > Any content encoding handled by zlib is now done with the stream
filter 'zlib.inflate' to handle on the fly decompression.
> Not always available, and once again needs to have a capability check on
Adding in feature detection for the `'dechunk'` and `'zlib.inflate'`
stream filters, creating custom filters, and registering those instead
appears possible in order to maintain support with PHP 5.2. It seems many
of the `stream_*` functions were added in PHP 5.
`stream_notification_callback` was added in 5.2 but that should be allowed
and would enable a path to non-blocking IO and multiple simultaneous
> Theoretically servers shouldn't respond with Chunked encoding if we
don't ask for it, nor should they supply compressed content we haven't
specified we can understand, so both of these shouldn't be an issue.
Yeah, I was testing requests with both HTTP/1.0 and HTTP/1.1 and other
permutations with Accept-Encoding. The servers I was using in my testing
all sent the correct data in the proper format as you mentioned most will.
> Note that #33055 is a proposal (which I believe most of us are behind)
to deprecate and remove WP_HTTP in preference for a more fleshed out
This is the first time I've come across the Requests library. I quickly
read over the code in GitHub so it's very possible I'm not seeing
everything. It looks like a lot of the same code currently in WP_HTTP when
going down the "fsockopen" (stream) transport path. The proxy, chunked,
and decode handling all look very similar and would be missing the
benefits of the patch in this ticket. Not to say Requests couldn't be
updated with these proposed changes though.
Since Guzzle was brought up, I'm not sure it handles tunneled proxy
connections either. I haven't spent any time looking at their code but a
couple of grep's aren't turning much up. So it's entirely possible I'm
missing the HTTP CONNECT call for encrypted or open proxy connection
tunneling. But, ultimately, like the other ticket discussed, getting
Guzzle to run on PHP 5.2 would be a hefty task.
If you're open to it, I'd like to take a crack at adding in the 5.2
compatibility to these patched changes (php_user_filter seems straight
forward). I think the streams API can be leveraged and still maintain PHP
5.2 compatibility. Parallel/Multiple requests and the filter/hook cleanup
would follow. This code should be useful no matter what given Requests has
roots from WP_HTTP.
Ticket URL: <https://core.trac.wordpress.org/ticket/36280#comment:2>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac