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 <Bad Request>
> because
> of the space in "to here.html"
>
> The asp code for the fromhere.asp is
> -----------------
> p = "http://www.hedaal.nl/tmp/to here.html"
> Response.Status="301 Moved Permanently"
> Response.AddHeader "Location", p
> ----------------
This is done by the browser automatically -- IE and other clients have
built-in mechanisms to encode all URLs prior to sending the request.
This is meant to work around the fact that most users can't (and
shouldn't have to!) type URLs in a properly encoded format. By
performing this task at the last moment possible, then as a bonus all
requests are encoded, whether the user typed it in, or it was captured
from a link, an FTP file list, or a redirect response. This is an
application behavior and I do not think it should be part of the
underlying transport component.
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
should go at the point of actually sending the response, to make sure
that *any* URL requested is encoded properly, regardless of where it
was captured (user, redirect response, etc.).
dZ.
--
DZ-Jay [TeamICS]
http://www.overbyte.be/eng/overbyte/teamics.html
--
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
