Because a GET reques affects the URL imagine you requested: mypage.php?id=errant
and the server responded 302 wit hthis url: mynewpage.php?redirect=fromold You now have to check for parameters on the URL and make sure they dont get forgotten (admittedly not a huge problem). but then what if the new page did not use the GET parameter of "id" and instead used "user" (not unlikely or uncommon). returning: mynewpage.php?user=errant would be fine but mynewpage.php would not be.... (as you would lose what user it was). The idea of 3xx codes is to allow devs/hosts to redirect content from old to new formats :) disregarding POST requests (and so forth), which are harder to handle anyway, the content of GET data should be static from one request to the next - but the PARAMETERS may change. So it has to be handled. (we had a very LONG lecture on this by TBL once :)) Thomas Morton ++ No problem should ever have to be solved twice ++ 2008/11/24 Ronny Schedel <[EMAIL PROTECTED]> > > I disagree. But I did not find any proof in the RFC (I was too lazy to read > all). But, look from a logic point of view. If you would have POST or > COOKIE > parameters, you always have to send these data to the new location, so why > not GET parameters too? > > > > Regardless of that (I agreehe needs to look into handling other > > eventualities: or at least exit gracefully). However Valve have still got > > their 302 wrong - it should come back with the ?xml=1 on the end (or, > > whatever param they decide is needed etc.). Which I think is the cruial > > point ;) > > > > > > Thomas Morton > > > > ++ No problem should ever have to be solved twice ++ > > > > > > 2008/11/24 Ronny Schedel <[EMAIL PROTECTED]> > > > >> This is what you would like to get, but this is not how the Internet > >> works > >> and can work. You should be aware of how the Internet works. Imagine > your > >> application gets very popular and the webserver requests increases very > >> high, Valve have two options which can hurt your application: > >> > >> 1. They can block or limit the access, so you have to take care if they > >> send > >> you 400's or 500's if the server is overloaded. > >> 2. They can install new servers to handle the higher load. Some load > >> balancing strategies depend on different server names, so you have to > >> take > >> care again of 300 reponse codes. > >> > >> > I'm aware that this is how it works (and I already do it this way as a > >> > workaround), but the behaviour on Valve's end should be consistent. If > >> > I > >> > request a profile's XML feed based on their 64-bit ID, I should get > >> > that > >> > profile's XML feed, not *either* what I requested *or* a redirect to > >> > the > >> > wrong place. > >> > >> > >> _______________________________________________ > >> To unsubscribe, edit your list preferences, or view the list archives, > >> please visit: > >> http://list.valvesoftware.com/mailman/listinfo/hlds > >> > > _______________________________________________ > > To unsubscribe, edit your list preferences, or view the list archives, > > please visit: > > http://list.valvesoftware.com/mailman/listinfo/hlds > > > > > _______________________________________________ > To unsubscribe, edit your list preferences, or view the list archives, > please visit: > http://list.valvesoftware.com/mailman/listinfo/hlds > _______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds
