Who doesnt!
;) Thomas Morton ++ No problem should ever have to be solved twice ++ 2008/11/24 Spencer 'voogru' MacDonald <[EMAIL PROTECTED]> > I'm human and I want to look at XML. > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Sebastian Staudt > Sent: Monday, November 24, 2008 8:58 AM > To: Half-Life dedicated Win32 server mailing list > Subject: Re: [hlds] Steam Community URLs and XML > > 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 > > > _______________________________________________ > 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
