There's no need to redirect at all. The data accessed by "/profiles/STEAMID64" and "/id/CUSTOMURL" is the same and therefore - I hope for Valve's web programmers - handled by the same controller. There's no need to redirect. Valve only uses this to "convert" the numeric IDs to human-readable strings. This is only done for the (human) user - and humans don't want to look at XML. ;)
2008/11/24 Thomas Morton <[EMAIL PROTECTED]> > 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 > _______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds