> The main issue is however that with the followrelocate
> set it will generate an error while a browser will not.

As has been stated before, that is not the main
issue.  The main issue is that the HttpCli component
does not perform *any* encoding of URLs prior to
sending a request to the server, which runs contrary
to the behaviour of any standard browser.  It just so
happens that the problem manifested itself in your
case as a relocation address with as space on it.

I do not agree that this is a relocation-specific
issue, and if we want the component to mimic the
expected behaviour of standard browsers, it needs to
automatically encode all URLs when composing the
request, at the latest point when the location
address has been "commited" immutably.

This means that it has to compensate for pre-encoded
URLs (just like standard browsers do: give IE an
encoded URL and it will leave it alone, give it one
with funky characters and it will encoded it).

      -dZ.


>------- Original Message -------
>From    : Frans van Daalen[mailto:[EMAIL PROTECTED]
>Sent    : 4/19/2007 3:58:57 PM
>To      : twsocket@elists.org
>Cc      : 
>Subject : RE: Re: [twsocket] httpcli v6 "bad request"
>
 >my 2 cents on this :

If you feed Thttpcli.url with a invalid url no
urldecode is executed. To 
keep consistency in behavior I would not just do an
automatic urldecode on a 
relocate.

The main issue is however that with the
followrelocate set it will generate 
an error while a browser will not.

To allow a programmer to make a decision on an
invalid relocate url the 
component must provide an option to do so.

I therefore see 3 possible solutions.

1) A new property AutoDecodeRelocationUrl  type
Boolean. Default FALSE. If 
set TRUE will execute a urldecode on the relocate AND
possible on the 
httpcli.url also. But if it include the later option
as well the name maybe 
should be AutoUrlDecode.

2) A new event OnRelocationRecieved(data : String;
Accept : Boolean) to be 
called around line 2675 (procedure getheaderlinenext)
----------------------------------
                { 
co=32&js=1.4&sr=1024x768&re=
http://www.thesite.com/you.html  }
                FLocationFlag := TRUE;
                if Proxy <> '' then begin
----------------------------------
something like
----------------------------------
                { 
co=32&js=1.4&sr=1024x768&re=
http://www.thesite.com/you.html  }

   baccept := true;
   if Assigned(FOnRelocationRecieved) then 
FOnRelocationRecieved(data,baccept);
   If baccept then

                FLocationFlag := TRUE;
                if Proxy <> '' then begin
----------------------------------
This would allow the programmer to temporary overrule
the FFollowRelocation 
setting on demand but also allow adjustment of the
received header data. I 
think that would enhance flexibility.

3) A change to the procedure getheaderlinenext to
just change the received 
data. In my opion not the best option as it can cause
confusion about what 
is really received.

Feedback appreciated :>>


-- 
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

Reply via email to