You are not logged in.
Pages: 1
Still I have something that bugs me, though I'm not sure if it's a true error somewhere:
The server specifies a header "Content-Encoding: deflate" but sends zlib-data. That is: I can successfully decode it with Synopse's CompressZLib. In the final application I have been able to implement that by hacking "result := 'deflate';" in CompressZLib. On the other hand I cannot find a spec for HTTP-headers that speaks of a zlib-content-encoding. So how should I know if data is zlib- or deflate-encoded?
So far I have a working application but there must be a "proper" way to distinguish between those, without hacking into SynZip?
..unless the server incorrectly specifies "Content-Encoding: deflate" for the gzip-encoded data. It's not actually a JBoss-issue btw but some custom software I'll have to fight our Java-dev about. SynCrtSock imho rightfully assumes the header is accurate about the datatype but it clearly isn't.
Are you sure your buffer is a real "deflate" content?
After some (long) investigation on our side, we found out that:
When I use the regular ZLib library, as shipped with Delphi, we have got the same error:
[...]Sounds like a bug in your version of JBoss, or a misconception on your side of deflate / zlib encodings.
Thank you for your great effort in helping me and my apologies for accusing your software of having a bug. Since Synopse/WinHttp is the "new" part in the chain, replacing Indy, I incorrectly supposed the problem must be in the new part. I tried interpreting the data as gzip but must have made another mistake there.
I can reproduce it with this:
program mORMot_Issue;
{$APPTYPE CONSOLE}
uses
SysUtils, SynZip;
const
{
Data as captured in Wireshark:
0000 78 9c 35 cc 31 0a 80 30 0c 05 d0 dd 53 c4 1e 40 x.5.1..0....S..@
0010 71 af 05 51 6f e0 56 1c 04 3f d2 c1 b4 24 51 f0 q..Qo.V..?...$Q.
0020 f6 e2 e0 fe 78 5e a0 25 b3 82 6e 88 a6 cc bd eb ....x^.%..n.....
0030 1c a9 6d 76 69 ef 66 91 2c 2e f8 3a 8e d3 b0 0c ..mvi.f.,..:....
0040 71 16 4a 4a 00 53 62 83 30 48 1f 35 e0 24 7c 92 q.JJ.Sb.0H.5.$|.
0050 72 39 60 82 1d dc ac 6b f0 ed 9f 87 ea 05 7a 0a r9`....k......z.
0060 24 aa $.
Decoded by Wireshark:
<response version="1" status="Error"><![CDATA[Er is een interne systeem error opgetreden.]]></response>
}
Data: RawByteString =
#$78#$9c#$35#$cc#$31#$0a#$80#$30#$0c#$05#$d0#$dd#$53#$c4#$1e#$40 +
#$71#$af#$05#$51#$6f#$e0#$56#$1c#$04#$3f#$d2#$c1#$b4#$24#$51#$f0 +
#$f6#$e2#$e0#$fe#$78#$5e#$a0#$25#$b3#$82#$6e#$88#$a6#$cc#$bd#$eb +
#$1c#$a9#$6d#$76#$69#$ef#$66#$91#$2c#$2e#$f8#$3a#$8e#$d3#$b0#$0c +
#$71#$16#$4a#$4a#$00#$53#$62#$83#$30#$48#$1f#$35#$e0#$24#$7c#$92 +
#$72#$39#$60#$82#$1d#$dc#$ac#$6b#$f0#$ed#$9f#$87#$ea#$05#$7a#$0a +
#$24#$aa;
var
EncodedData: RawByteString;
DecodedData: RawByteString;
begin
EncodedData := Data;
DecodedData := CompressDeflate(EncodedData, False);
Writeln(DecodedData);
Readln;
end.
My code (that is not the code in the quote here) basically does this:
fWinHttp := TWinHTTPCreate(hostname, 0, false);
fWinHttp.RegisterCompress(CompressDeflate);
and then a handful of Request()s: a GET with a redirect, a second GET with a plain answer, a POST with a redirect and then the GET from the redirect with a deflated response. The last response is the only one using deflate and the thus the only (or, I'm afraid: "the first" ) one failing.
I am using the latest ("trunk") SynCrtSock in a Delphi 6 application (client requirement, don't ask..) to make a connection to a JBoss-webservice. Some of this works but when I receive deflated data (i.e. CompressDeflate is registered) this fails with a "-3" error code, this seems to mean "invalid compressed data".
Some research reveals that in this case the compressed data contains a null-character (ascii-value = 0) that terminates a string somewhere in the middle. It seems to me that is is incorrect to use the datatype string to contain possibly binary data. This should be some kind of a bytearray (as is returned by winhttpreaddata).
I have not yet confirmed that using a bytearray instead of string works but will report if it does. Since I'm working on it on my client's time, I will not be able to post the code for the fix because of possible copyright-infringement.
Pages: 1