> 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