Do you have a question? Post it now! No Registration Necessary. Now with pictures!
- Posted on
- SOAP and Accept-Encoding
April 29, 2007, 9:11 pm
rate this thread
the response (by sending the Accept-Encoding header). To do this, I'm
sending 'compression' => SOAP_COMPRESSION_ACCEPT |
SOAP_COMPRESSION_GZIP in the SoapClient constructor's options.
But when I print the request headers, I don't see the Accept-Encoding
header. Am I doing something wrong?
I also tried SOAP_COMPRESSION_ACCEPT | SOAP_COMPRESSION_GZIP | 9 to
set the compression level, as I've seen in some examples.
I just downloaded and compiled php 5.2.1 with --enable-soap on Mac OS
The full example is below:
$o_client = new SoapClient($wsdlURL, array(
'trace' => true,
'compression' => SOAP_COMPRESSION_ACCEPT | SOAP_COMPRESSION_GZIP,
'login' => $login,
'password' => $password
$o_result = $o_client->acknowledge();
Re: SOAP and Accept-Encoding
I don't see anything wrong with the way you're trying to use
compression, but setting the compression level like this bothers me.
It doesn't make much sense, binary operators shouldn't work like that.
When you pass flags with the pipe, the flags are powers of two so that
they each have a one in a different place in the binary byte, for
example whichever flag was given the value of 2 would be 00000010, the
next flag would be given the value of 4 (00000100), the next would be
8 (00001000). The binary or operator (|) will return a number that has
ones in all places on the other numbers where there is a one, IE:
define( 'SOAP_COMPRESSION_ACCEPT', 2 ); // 00000010
define( 'SOAP_COMPRESSION_GZIP', 4 ); // 00000100
define( 'SOME_OTHER_CONSTANT', 16 ); // 00010000
echo SOAP_COMPRESSION_ACCEPT |
the flags are combined, yielding 00010110, which is binary for 22, so
it will echo the number 22. Now, when you also combine in the number
9, which is 00001001, you will get 00011111. This messes things up
because normally the receiving function, something like this...
function doStuff( $flags )
if( $flags & SOME_OTHER_CONSTANT )
...might get confused. The function will be checking to see where the
ones are (with the & operator), and an arbitrary number could throw in
a one anywhere, so it's left with complete BS. It will then have
unexpected consequences because it will see the one somewhere that
some unrelated flag would normally put a one. So there goes the
setting compression level thing.
BTW, where did you see those contrary examples?
Re: SOAP and Accept-Encoding
I'm assuming that the flags were designed with that in mind, so the
SOAP_COMPRESSION_ flags are large enough numbers that they don't
interfere with the compression-level number. I agree that it's a weird
design. The compression level isn't documented, but I found a
reference to it in this bug:
I'm not sure whether that's been incorporated into PHP 5.2.1, though.