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] 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
smime.p7s
Description: S/MIME cryptographic signature
