Closed birdspider closed 10 years ago
Can you try the latest version and report back? I will close this until then.
I see the codebase changed quite a bit. I wrote a workaround back when I reported the issue. I'm sorry I can't test this as-is.
But it should be easy to do a html from with multipart/form-data
and check if $_POST is filled on the behind-proxy-side.
Anyway thank you for looking into it.
The current code now uses Symfony request/response objects and Guzzle to send and receive the requests. It makes it more flexible and easier to use for developers.
l am using the basic example code. POST url encoded or JSON is not sent with the redirect. Is there something l am missing.
I have the same problem, the multipart post content is not transmitted to the proxified target, i'm not sure where the posted data gets lost as I debugged and reached the guzzle client stream_for php//input Is a multipart/form-data; boundary=----WebKitFormBoundaryblabla.. Tried using the guzzle5 branch with symphony, but no option for stackhandlers with guzzle v5 .
Since multipart requests don't work with "php://input", I had to rebuild the request for the guzzle multipart option, example:
$gzOptions = [
'verify' => false,
'cookies' => true
];
#PATCH for multipart requests.
if ( $_SERVER['REQUEST_METHOD'] === 'POST' && stristr( $_SERVER['CONTENT_TYPE'], 'multipart' ) ) {
unset( $_SERVER['CONTENT_TYPE'] );
//Run Request Factory AFTER, not before.
$multipart = urldecode( http_build_query( $_POST ) );
$multipartArr = strstr( $multipart, '&' ) ? explode( '&', $multipart ) : [ $multipart ];
foreach ( $multipartArr as $pair ) {
$pairArr = strstr( $pair, '=' ) ? explode( '=', $pair ) : [ $pair ];
$gzOptions['multipart'][] = [ 'name' => $pairArr[0], 'contents' => isset( $pairArr[1] ) ? $pairArr[1] : '' ];
}
}
$guzzle = new GuzzleHttp\Client( $gzOptions );
// Create a PSR7 request based on the current browser request.
$request = ServerRequestFactory::fromGlobals();
If this can be simplified then I would love to hear in case I'm missing something.
Any updates on this?
If there is a POST request with multipart/form-data it gets reencodeed as application/x-www-form-urlencoded
(see: https://github.com/jenssegers/php-proxy/blob/master/proxy.php#L247)
but the multipart/form-data Content-Type Header stays - which in effect drops the POST data