Since you rae writing a page check software, it is probably ggod
enough to not handle the cookies and to refuse relocation if the
url is the same url.
That did occur to me, unfortunately the LocationChange event does not
have the AllowMoreRelocations parameter that the
Is it valid for an HHTP header to relocate to an empty URL?
Currently, HttpProt seems to parse the relocation to the same URL, and
goes into a loop.
HTTP/1.1 302 Found
Location: http://
Temporary Redirection: http://www.telecomstrader.com/ to:
http://www.telecomstrader.com/
Angus
--
To
an...@magsys.co.uk
To: twsocket@elists.org
Sent: Thursday, May 20, 2010 1:12 PM
Subject: [twsocket] HTTP Location
Is it valid for an HHTP header to relocate to an empty URL?
Currently, HttpProt seems to parse the relocation to the same URL, and
goes into a loop.
HTTP/1.1 302 Found
Location
The temporary URI SHOULD be given by the Location field in the
response. Unless the request method was HEAD
I am using the HEAD method, this is a web site checker confirming 1,500
URLs in a database still exist each week... I'll try GET.
Angus
--
To unsubscribe or change your settings for
On May 20, 2010, at 05:59, Angus Robertson - Magenta Systems Ltd wrote:
The temporary URI SHOULD be given by the Location field in the
response. Unless the request method was HEAD
I am using the HEAD method, this is a web site checker confirming 1,500
URLs in a database still exist each
Not exactly what I said ;-)
I said that irrespective to what RFC could imply, some sites intentionally
use redirection to the same location, and the site (server) should normally
prevent endless looping. If it's not, than indeed a client should protect itself
- whether it is implemented in
It is not clear to me from the spec, but if it makes the express
assertion that it SHOULD give the new URI in the response to
non-HEAD requests, by omission it seems to me that it then MUST
do so for HEAD.
It's not unusual for servers to treat HEAD differently, I had to fix the
ICS web
