#1 Re: mORMot 1 » Bug in SynCrtSock: TWinHTTP.InternalReadData, string or bytearray » 2014-07-18 13:06:55

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?

#2 Re: mORMot 1 » Bug in SynCrtSock: TWinHTTP.InternalReadData, string or bytearray » 2014-07-18 11:54:05

..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. smile SynCrtSock imho rightfully assumes the header is accurate about the datatype but it clearly isn't.

#3 Re: mORMot 1 » Bug in SynCrtSock: TWinHTTP.InternalReadData, string or bytearray » 2014-07-17 08:14:12

ab wrote:

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.

#4 Re: mORMot 1 » Bug in SynCrtSock: TWinHTTP.InternalReadData, string or bytearray » 2014-07-16 13:45:57

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" smile ) one failing.

#5 mORMot 1 » Bug in SynCrtSock: TWinHTTP.InternalReadData, string or bytearray » 2014-07-16 11:40:32

Bacchus
Replies: 10

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.

Board footer

Powered by FluxBB