Re: [twsocket] Adding gzip to HttpCli

2005-08-01 Thread Maurizio Lotauro
On 30-Jul-05 01:54:44 Maurizio Lotauro wrote:

>On 28-Jul-05 08:34:58 Francois Piette wrote:

>>> Do you want that the data passed to OnDocData is decompressed?

>>Yes I do.

>Are you really sure? Ok Ok, I'll try to do it :-)

Done.

Now I have some points that I would like to discuss.

a) Exception in THttpContentCoding.GetCoding method
This method is called indirectly during the initialization. It seems
that this is not the best moment to raise an exception.
When run from Delphi, if the "Stop on Delphi exception" is not
enabled, the developer see only an "Internal error 217 on ...", not
very meaningful to know what the problem is. For the same reason is
useles to have a spefic exception class.
If run outside Delphi the user see "This application has encounterd
bla bla bla do you want send a report bla bla bla".
I tried to move the check in the THttpContCodHandler.Create. In this
case when run from Delphi the developer will see what specific
exception is raised. Outside Delphi same behaviour same message "This
application ..."
I would prefer the first approach because the error is raised when
the application will run, while the second only when the form or
datamodule that contain the component will created. But the error
message will disoriunt the developer if he has "Stop on Delphi
exception" disabled. Opinions?

b) New properties.
We need at least two new properties. One for disable the automatic
use of content coding and another to enable the use of Quality
specifier. I suggest to use a record type to group all properties
related to the content coding. The property could be "ContentCoding"
with "Enabled" (default false) and "UseQuality" (default false)
fields.
If it is not enabled the component will not add the "Accept-Encoding"
in the header. Should it even ignore then "Content-Encoding"?

c) The THttpContCodHandler.Prepare return false if there is an encode
that it is unable to decompress. Actually the HttpCli doesn't check
the result, and in this case the body will be not decompressed at
all. Is it acceptable or should this situation be handled differently?

d) There are two coding atomatically added: "Identity" (quality=0.5)
and "*" (quality=0). Actually they are enabled by default, should
they must disabled?
Is it ok the default value of quality?

That's all for the moment.


Bye, Maurizio.

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


Re: [twsocket] [TMimeDec] Preamble and Epilogue

2005-08-01 Thread Francois Piette
Piotr,

Can you provide an enhanced unit with your fixes ?
Remember that the fixes should not break existing code !

--
[EMAIL PROTECTED]
http://www.overbyte.be

- Original Message - 
From: "Piotr Hellrayzer Da³ek" <[EMAIL PROTECTED]>
To: "TWSocket" 
Sent: Saturday, July 30, 2005 4:20 PM
Subject: [twsocket] [TMimeDec] Preamble and Epilogue


> Hi!
>
> TMimeDec does NOT ignore MIME preamble and epilogue, so it fails to decode
> correctly complex multipart message from RFC 2049 Appendix A. Specifically,
> when it sees ending boundary ("--boundary--") it starts another part.
>
> Disabling preamble parsing as text/plain is very simple, just have to
> check in OnHeaderEnd if the ContentType starts with "multipart/" - if so,
> we have to ignore next "part". With preambles and epilogues of embedded
> parts is far worse. Let's see the ProcessPartLine:
>
> procedure TMimeDecode.ProcessPartLine; { ##ERIC }
> var
> Len : Integer;
> t   : Integer;
> s   : String;{ ##ERIC }
> begin
> { Check if end of part (boundary line found) }
> if (FCurrentData <> nil) and (FCurrentData^ <> #0) then begin
> s := LowerCase(StrPas(FCurrentData));
> if (s = FBoundary) then begin
> PreparePart;
> exit;
> end
> else if (s = (FBoundary + '--')) then begin
> FEndOfMime := TRUE;
> PreparePart;
> exit;
> end
> else begin
> for t := 0 to FEmbeddedBoundary.Count - 1 do begin
> if (s = FEmbeddedBoundary[t]) or
>(s = (FEmbeddedBoundary[t] + '--')) then begin
> { we now have to wait for the next part }
> PreparePart;
> exit;
> end
> end;
> end;
> end;
> [..]
>
> What do we see? When we hit epilogue of *the message*, we get information
> about that we're done with MIME (whatever that should mean...). We don't
> get *any* information if we crossed the ending boundary ("--boundary--")
> and start parsing epilogue. TMimeDec simply starts another part! My fix:
>
> procedure TMimeDecode.ProcessPartLine; { ##ERIC }
> var
> Len : Integer;
> t   : Integer;
> s   : String;{ ##ERIC }
> begin
> { Check if end of part (boundary line found) }
> if (FCurrentData <> nil) and (FCurrentData^ <> #0) then begin
> s := LowerCase(StrPas(FCurrentData));
> if (s = FBoundary) then begin
> PreparePart;
> exit;
> end
> else if (s = (FBoundary + '--')) then begin
> FPartOpened := False; //phd
> TriggerPartEnd;   //phd
> exit;
> end
> else begin
> for t := 0 to FEmbeddedBoundary.Count - 1 do begin
> if s = FEmbeddedBoundary[t] then begin //phd
> PreparePart; //phd
> Exit; //phd
> end else if s=(FEmbeddedBoundary[t] + '--')) then begin
> FPartOpened := False; /phd
> TriggerPartEnd; //phd
> exit; //phd
> end
> end;
> end;
> end;
> [..]
>
> And I propose that we throw away that FEndOfMime. From my point of view,
> it's useless, and still eats that byte or four (if compiler aligns variables
> on dword boundaries).
>
> -- 
> Piotr "Hellrayzer" Dalek
> Author of ICS-Based Hellcore Mailer - an Outlook Express killer
> http://www.hcm.prv.pl
> [EMAIL PROTECTED]
>
> --
> Najlepszy serwis MOTO w Polsce! >>> http://link.interia.pl/f18a8
>
> -- 
> To unsubscribe or change your settings for TWSocket mailing list
> please goto http://www.elists.org/mailman/listinfo/twsocket
> Visit our website at http://www.overbyte.be
>

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