RE: [Kannel 0000010]: HTTP requests get urlencoded twice (orevenmore) if HTTP 302 (redirect) responses are received

I think you answered your question yourself :).
Yes, the querystring should be included in subsequent requests.

-- Rene...

-----Original Message-----
From: [email protected] [mailto:[email protected]]On Behalf Of
Bruno David Rodrigues
Sent: dinsdag 25 maart 2003 17:08
To: [email protected]
Subject: RE: [Kannel 0000010]: HTTP requests get urlencoded twice
(orevenmore) if HTTP 302 (redirect) responses are received


Citando Rene Kluwen <[email protected]>:

> About 302 (temporary) redirecting responses:
>
> After a GET request, the client (kannel) should redirect the SAME
request
> to the URL pointed to in the Location: header.
> This means, the query string should not re-urlencoded.

Section 3.2.2 says that URL includes the querystring, so going back to my
first
question - should the original querystring be added to the new location ?

Imagine this:
original URL: http://foobar/foo?phone=%p&text=%a
Location header: http://barfoo/bar?foo=true&bar=false

Which URL should kannel use ? Simply the location ? should it add
"phone...%a"
to the second URL (http://barfoo....bar=false&phone=%p&text=%a) ?
I don't see anything relevant in rfc :(


> After a POST request, the same request should be POSTed the the new URL.
> Specs tell that this should require user interaction, "since this might
> change the conditions under which the request was issued". But I figure,
> this will be a little hard, as Kannel is a daemon.

No, it says "MUST NOT go without user intervention". As kannel is a
daemon, it
shouldn't follow locations if original method is a post. Unless we have a
config
value "yes-i-ve-read-rfc-and-i-want-to-follow-post-redirections = true" ;)


> The above also goes when the status code is 301 (Moved permanently). But
> Kannel should save the new URI's and use them for future connections.

Should we have a url cache system ? Should we bother with it ? does IE do
it ? ;)


> The 303 status (See Other) is an exception. The new URI given in the
> response should be retrieved using a GET method.

This one is cute. You do your job at first location then server replies
"thanks
for your job, now go there for more information"

> -- Rene...

Thx


--
<br/>
 15:56:22 up 122 days, 17:10,  1 user,  load average: 0.00, 0.01, 0.41
BOFH excuse #172:
pseudo-user on a pseudo-terminal