[wp-trac] [WordPress Trac] #36280: HTTP API (Streams backend) secured proxy tunnels and chunked and zlib on the fly streaming

[WordPress Trac]

#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
 it.
 >
 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
 requests.
 > 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
 library.
 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