remove my email from this list... ------------------DigiVoice------------------ | Luciano Alves Barroso | E-Mail: [EMAIL PROTECTED] | Tel.: (11)2191-6362 | Site: http://www.digivoice.com.br | http://www.meucci.org -------------Desenvolvimento------------
------------- Segue mensagem original! ------------- De: "Francois PIETTE" <[EMAIL PROTECTED]> Data: Fri, 20 Apr 2007 19:17:40 +0200 Para: "ICS support mailing" <twsocket@elists.org> Assunto: Re: [twsocket] httpcli v6 "bad request" > 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. I don't think the component has to encode all URL, specialy surely not encode the URL provided in the URL property. This would break a lot of existing code. BUT, in the relocation process, it is OK to encode any URL involved because the user has no effective acces to this URL. -- Contribute to the SSL Effort. Visit http://www.overbyte.be/eng/ssl.html -- [EMAIL PROTECTED] http://www.overbyte.be ----- Original Message ----- From: <[EMAIL PROTECTED]> To: <twsocket@elists.org> Sent: Thursday, April 19, 2007 10:30 PM Subject: Re: [twsocket] httpcli v6 "bad request" > >> 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 -- 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
