DZ-Jay wrote:
> The
> alternative would be to give the user access to the URL when
> automatic redirections are in place, via a new event.
For this purpose I suggest we trigger the OnHeaderData event at
a slightly different place and make property LastResponse
writeable.
> However,
> Francois
On Apr 23, 2007, at 14:52, Arno Garrels wrote:
> What needs to be changed is the fact that component users currently
> cannot
> correct a badly formed (Location) header line.
>
> If I use the THttpCli just to connect to my own servers I don't need
> the
> overhead of any smart check because I c
DZ-Jay wrote:
>
> As I mention above, I now see the reason to treat the redirection as a
> special case and I agree that it should be done. However, I still
> think it should be done with a pseudo-smart mechanism that will
> account for percent symbols that are literal or escape characters.
What
overbyte.be
- Original Message -
From: "Arno Garrels" <[EMAIL PROTECTED]>
To: "ICS support mailing"
Sent: Sunday, April 22, 2007 11:41 AM
Subject: Re: [twsocket] httpcli v6 "bad request"
> The easiest workaround is to trigger event OnHeaderData in
> Get
The easiest workaround is to trigger event OnHeaderData in
GetHeaderLineNext right before FLastResponse is added to
FRcvdHeader. OnHeaderData could get a new var parameter,
that is filled with FLastResponse.
Or we simply make property LastResponse writeable which
won't even require a change of eve
Frans van Daalen wrote:
> From: "Arno Garrels"
>>
>> Instead the component should provide access to parts of a URL,
>> either by var-parameters in event OnLocationChange
>
> As said before the OnLocationChange is to late. That event is
> triggered just before the relocate will execute. All proper
>
>
> - Original Message -
> From: "Arno Garrels" <[EMAIL PROTECTED]>
> To: "ICS support mailing"
> Sent: Saturday, April 21, 2007 1:35 PM
> Subject: Re: [twsocket] httpcli v6 "bad request"
>
>
>> Francois PIETTE wrote:
> A faster and more copmlete function UrlEncode should
> be made available.
Here's my faster suggestion, only I'm not sure about the characters
allowed in a complete URL, may be someone has the idea?
function UrlCheckEncode(const S: String): String;
const
UrlAllowedChars : TCharSet = ['a'..'
ect time.
--
Contribute to the SSL Effort. Visit http://www.overbyte.be/eng/ssl.html
--
[EMAIL PROTECTED]
http://www.overbyte.be
- Original Message -
From: "Arno Garrels" <[EMAIL PROTECTED]>
To: "ICS support mailing"
Sent: Saturday, April 21, 2007 1:35 PM
From: "Arno Garrels"
>
> Instead the component should provide access to parts of a URL,
> either by var-parameters in event OnLocationChange
As said before the OnLocationChange is to late. That event is triggered just
before the relocate will execute. All properties of the thttpcli are then
alre
Francois PIETTE wrote:
>> If you think -- like me -- that it is the
>> responsibility of the application developer to
>> properly encode URLs, and not the component, then the
>> solution for those applications that require the
>> IE-like behaviour is for the developer to call
>> UrlEncode himself
> Francois,
> Then there are situations that your previous
> argument will fail: Consider an application using
> HttpCli that does not automatically encode URLs in
> the URL property. Users will complain that "If I
> enter in IE it works, but your
> software is broken!". If your response is "
ois
PIETTE[mailto:[EMAIL PROTECTED]
>Sent: 4/20/2007 1:17:40 PM
>To : twsocket@elists.org
>Cc :
>Subject : RE: Re: [twsocket] httpcli v6 "bad request"
>
>> I do not agree that this is a relocation-specific
> issue, and if we want the component
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:
Sent: Thursday, April 19, 2007 10:30 PM
Subject: Re: [twsocket] httpcli v6 "bad request
Original Message ---
>From: Arno Garrels[mailto:[EMAIL PROTECTED]
>Sent: 4/20/2007 10:41:53 AM
>To : twsocket@elists.org
>Cc :
>Subject : RE: Re: [twsocket] httpcli v6 "bad request"
>
>[EMAIL PROTECTED] wrote:
>> --- Original Message --
[EMAIL PROTECTED] wrote:
>> --- Original Message ---
>>> From: Francois
> PIETTE[mailto:[EMAIL PROTECTED]
>> Sent: 4/19/2007 2:46:48 PM
>> To : twsocket@elists.org
>> Cc :
>> Subject : RE: Re: [twsocket] httpcli v6 "ba
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:
>--- Original Message ---
>From: Francois
PIETTE[mailto:[EMAIL PROTECTED]
>Sent: 4/19/2007 2:46:48 PM
>To : twsocket@elists.org
>Cc :
>Subject : RE: Re: [twsocket] httpcli v6 "bad request"
>
>>> Agreed, so we need a FAST rou
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.
T
>> Agreed, so we need a FAST routine. URLEncode currently
>> isn't smart enough to encode a complete URL, and it is
>> slow (result := result + ..)
>
> Next question is how smart should such a routine act?
> Should it check for a valid URL in general or shall it
> just check for valid encoding?
> S
Arno Garrels wrote:
> [EMAIL PROTECTED] wrote:
>>> --- Original Message ---
>>>> From: Arno Garrels[mailto:[EMAIL PROTECTED]
>>> Sent: 4/19/2007 6:37:09 AM
>>> To : twsocket@elists.org
>>> Cc :
>>> Subject : RE
[EMAIL PROTECTED] wrote:
>> --- Original Message ---
>>> From: Arno Garrels[mailto:[EMAIL PROTECTED]
>> Sent: 4/19/2007 6:37:09 AM
>> To : twsocket@elists.org
>> Cc :
>> Subject : RE: Re: [twsocket] httpcli v6 "bad request"
> Frans,
> As I mentioned before, replacing spaces will still
> leave you open to other invalid characters. If you
> want a quick fix for your current problem, then I
> suggest URL-encoding the entire URL instead of just
> the the spaces. Its been a while since I've used
> HttpCli, so I'm not s
ve already been encoded
by the application externally.
-dZ.
>--- Original Message ---
>From: Frans van Daalen[mailto:[EMAIL PROTECTED]
>Sent: 4/19/2007 6:54:57 AM
>To : twsocket@elists.org
>Cc :
>Subject : RE: Re: [twsocket] httpcli v6 "bad re
>--- Original Message ---
>From: Arno Garrels[mailto:[EMAIL PROTECTED]
>Sent: 4/19/2007 6:37:09 AM
>To : twsocket@elists.org
>Cc :
>Subject : RE: Re: [twsocket] httpcli v6 "bad request"
> No idea, I can only see that the send header i
> > No idea, I can only see that the send header in this case will have
> > the %20 included already.
>
> In my Ethereal dump the location-header of the 301-response already has
> the space, so the server simply tries to redirect to an invalid URL, do
> we really have to workaround such invalid URL
>
> In my Ethereal dump the location-header of the 301-response already has
> the space, so the server simply tries to redirect to an invalid URL, do
> we really have to workaround such invalid URLs in the THttpCli?
>
With followRelocation := True this URL will generate a 400 on ThttpCli with
abs
Frans van Daalen wrote:
> - Original Message -
> From: "DZ-Jay" <[EMAIL PROTECTED]>
> To: "ICS support mailing"
> Sent: Thursday, April 19, 2007 11:44 AM
> Subject: Re: [twsocket] httpcli v6 "bad request"
>
>
>>
>> O
>
> Notice that replacing spaces may not suffice, as it may fail too if any
> other unencoded character is included; so if you want HttpCli to handle
> it, I would suggest rather a call to an HTML-Encode function for the
> URL prior to posting the response. However, I still think that this
> shoul
- Original Message -
From: "DZ-Jay" <[EMAIL PROTECTED]>
To: "ICS support mailing"
Sent: Thursday, April 19, 2007 11:44 AM
Subject: Re: [twsocket] httpcli v6 "bad request"
>
> On Apr 18, 2007, at 15:11, Frans van Daalen wrote:
>
>> Plea
On Apr 18, 2007, at 15:11, Frans van Daalen wrote:
> Please note that the following will cause the server to include a %20
> before
> sending the header
>
>
> p = "http://www.hedaal.nl/tmp/to here.html"
> response.redirect p
>
Are you sure it is the server
On Apr 18, 2007, at 15:11, Frans van Daalen wrote:
> I constructed a 301 page for you at www.hedaal.nl/tmp/fromhere.asp
>
> If you use IE this link will relocate you to
> http://www.hedaal.nl/tmp/to%20here.html
>
> If you use OverbyteIcsHttpTst it will give you a 400
> because
> of the space in
Hello:
Wouldn't it be more appropriate for the application to guarantee that
the URL conforms to RFC 1738 by encoding all illegal characters
(including spaces)? Common client applications (browsers) do this
automatically for the user, but it is still stupid for the server to
redirect y
the header
p = "http://www.hedaal.nl/tmp/to here.html"
response.redirect p
Frans
- Original Message -
From: "Frans van Daalen" <[EMAIL PROTECTED]>
To: "ICS support mailing"
Sent: Wednesday, April 18, 2007 6:49 PM
Subject: Re
place(httpclient.fpath,'
','%20',[rfreplaceall]);
in a onLocationChange event
Frans
- Original Message -
From: "Francois PIETTE" <[EMAIL PROTECTED]>
To: "ICS support mailing"
Sent: Wednesday, April 18, 2007 2:38 PM
Subject: Re: [twsocket] httpcli
van Daalen" <[EMAIL PROTECTED]>
To: "ICS support mailing"
Sent: Monday, April 16, 2007 7:29 PM
Subject: Re: [twsocket] httpcli v6 "bad request"
> arggg...found it!
>
> The location url contains a space. I'm now trying to solve this. Using the
>
arggg...found it!
The location url contains a space. I'm now trying to solve this. Using the
OnLocationChange to adjust the url doesn't work because of
---
THttpCli.StartRelocation
.
.
.
if Assigned(FOnLocationChange) then
FOnLocationChange(Self);
SaveLoc
>>>That appears correct, the THttpCli changes a POST to a GET request
>>>when automatically redirecting.
>>>
>>>RFC1945 however say that this is wrong:
>>
>> That's true. We found the same thing while building an interface to one
>> server. Note, however, the major browsers all change the POST to
>>That appears correct, the THttpCli changes a POST to a GET request
>>when automatically redirecting.
>>
>>RFC1945 however say that this is wrong:
>
> That's true. We found the same thing while building an interface to one
> server. Note, however, the major browsers all change the POST to a
> GE
At 12:24 AM 4/7/2007, you wrote:
>That appears correct, the THttpCli changes a POST to a GET request
>when automatically redirecting.
>
>RFC1945 however say that this is wrong:
That's true. We found the same thing while building an interface to one
server. Note, however, the major browsers all
DZ-Jay wrote:
[..]
> If I understand your problem, what is happening is this: You submit a
> Post request, the server responds with 302, the HttpCli automatically
> submits a Get request to the new location, but the server rejected it,
> ignored it, or processed it incorrectly because it was expec
>
> If I understand your problem, what is happening is this: You submit a
> Post request, the server responds with 302, the HttpCli automatically
> submits a Get request to the new location, but the server rejected it,
> ignored it, or processed it incorrectly because it was expecting a Post
> req
On Apr 5, 2007, at 13:38, Frans van Daalen wrote:
> The first postasync generate 302 from the server. As follow is set the
> httpcli will also do a get for the relocation.
What do you mean that it will do a Get for the relocation? A 302
relocation response just means that you have to request t
and fails somewhere/somehow?
Kind regards,
Frans
- Original Message -
From: "Francois PIETTE" <[EMAIL PROTECTED]>
To: "ICS support mailing"
Sent: Thursday, April 05, 2007 6:44 PM
Subject: Re: [twsocket] httpcli v6 "bad request"
> Maybe
Maybe some security product which filter your requests ?
--
Contribute to the SSL Effort. Visit http://www.overbyte.be/eng/ssl.html
--
[EMAIL PROTECTED]
http://www.overbyte.be
- Original Message -
From: "Frans van Daalen" <[EMAIL PROTECTED]>
To: "ICS support mailing"
Sent: Thursday, Ap
45 matches
Mail list logo
