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

Reply via email to