Re: [twsocket] deflate for OverbyteIcsHttpCCodZLib

[brian -]

This seems to be finally fixed in the latest Daily/SVN, the data received
is transparently uncompressed etc.

HOWEVER, there is a small issue, which isn't readily apparent unless you
check received data size etc:

If you don't include OverbyteIcsHttpCCodZLib anywhere in your app, it won't
be used at all even if you add content encoding in the httpcli object
options, so the getcoding/complete calls use the default
in OverbyteIcsHttpContCod instead and gzip isn't really used.

On Mon, Oct 8, 2012 at 10:50 AM, Angus Robertson - Magenta Systems Ltd 
an...@magsys.co.uk wrote:

  Tested with this website http://myanimelist.net/malappinfo.php
 
  If I enable content encoding, then the data received isn't
  compressed unless I add deflate.

 Whether the site compresses the data is not the issue, it's whether the
 ICS component can decompress anything with the change you proposed.  And
 my testing shows not.

 I suspect I know the reason, if a compression type of 'gzip, deflate' is
 added, it expects exactly that string to be returned, the component does
 not parse the separate words.

 Your test site also does not use deflate, testing with the ICS browser
 demo gives:

 [0]  GET /malappinfo.php HTTP/1.1
 [0]  Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, */*
 [0]  Connection: Keep-Alive
 [0]  Accept-Encoding: gzip, deflate

 [0]  HTTP/1.1 200 OK
 [0]  Date: Mon, 08 Oct 2012 08:41:14 GMT
 [0]  Server: Apache/2
 [0]  X-Powered-By: PHP/5.1.6
 [0]  Vary: Accept-Encoding
 [0]  Content-Encoding: gzip
 [0]  X-Served-By: app2v-mal.ao.prd.lax
 [0]  Content-Length: 76

 so it returns gzip not deflate, and ICS fails to decode the XML.

 Angus


 --
 To unsubscribe or change your settings for TWSocket mailing list
 please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket
 Visit our website at http://www.overbyte.be



--
To unsubscribe or change your settings for TWSocket mailing list
please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket
Visit our website at http://www.overbyte.be

[twsocket] exception after THttpCli.ReqDone causes double trigger of RequestDone

[brian -]

Hi, been experiencing something kinda odd, not sure if this is on purpose
or a bug somewhere:

After RequestDone with THttpCli, if there is an -unhandled- exception
before the code is out of ReqDone stack, RequestDone is triggered again.
Try the following code:

  httpcli1.RcvdStream := tmemorystream.Create;
   httpcli1.URL := 'google.com';
   httpcli1.Get;

 procedure TForm1.HttpCli1RequestDone(Sender: TObject; RqType:
 THttpRequest; ErrCode: Word);
 var ts: tstringlist;
 begin
   if rqtype  httpGET then exit;
   memo1.Lines.Add('req done');
   ts := tstringlist.Create;
   ts.Add('sdfdsf'); // 0
   caption := ts[1]; // list out of bounds, 0..1..2
 end;


You will see RequestDone is triggered twice, and external exception
handlers or delphi's don't trigger at all (e.g madExcept).
I know I can solve this by using try/except on the final code, or using
BgException (canclose := False), but why is this happening?
--
To unsubscribe or change your settings for TWSocket mailing list
please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket
Visit our website at http://www.overbyte.be

Re: [twsocket] exception after THttpCli.ReqDone causes double triggerof RequestDone

[Arno Garrels]

brian - wrote:
 After RequestDone with THttpCli, if there is an -unhandled- exception
 before the code is out of ReqDone stack, RequestDone is triggered
 again. 

[..]
 
 You will see RequestDone is triggered twice, and external exception
 handlers or delphi's don't trigger at all (e.g madExcept).

If you want MadExcept handle those exceptions add i.e. these lines
 
initialization
  SetIcsThreadLocalFinalBgExceptionHandling(fehAppHandleException);

This tells ICS to call the global Application's exception handler
for any unhandled background exception in main thread context rather 
than eat unhandled exceptions. 

 I know I can solve this by using try/except on the final code, or
 using BgException (canclose := False),

Indeed it's best practice to catch and handle all exceptions in the
event handlers. 

 but why is this happening?

It happens because Abort is called by default on unhandled exceptions
which in turn calls OnRequestDone() again.

-- 
Arno 
--
To unsubscribe or change your settings for TWSocket mailing list
please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket
Visit our website at http://www.overbyte.be