or better yet can you subclass the XMLDocument code to handle 302 responses?
Thomas Morton ++ No problem should ever have to be solved twice ++ 2008/11/24 Thomas Morton <[EMAIL PROTECTED]> > Ah right ok :) I see - so your handling the headers & data directly. > > So long as Valve stick to the standard protocol you should be able to > recognise the 302 response and do the second GET - but tweak it to make sure > that the xml-1 parameter makes it back to9o. > > i'd highly advise using a pre-built library that handles all the response > codes - so nothing can break in future :) > > Thomas Morton > > ++ No problem should ever have to be solved twice ++ > > > 2008/11/24 David Kellaway <[EMAIL PROTECTED]> > >> Regarding these points: >> >> Ronny Schedel wrote: >> >>> It's not working like you may think. If you access the page with 64bit >>> userid and a user friendly name is set, the webserver respond only a code >>> different from 202 with the new location (don't remember the code, it's 301 >>> or something). You don't receive any content. Your Internet browser just >>> handle this redirected page and display it. Even if Valve would pass all GET >>> parameters to the redirected page, the webserver would still respond with >>> the redirected page without content in the first step. >>> >>> >> 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. >> >>> An example (might have some typos): >>> >>> 1. You: GET /profiles/123456789/?xml=1 >>> 2. Webserver: 301 Location: http://steamcommunity.com/id/nicename >>> 3. You: GET /id/nicename?xml=1 >>> 4. Webserver: 202 Content-Length: ......... >>> >>> This is a rough overview what happens, experienced web programmers should >>> understand what happens. >>> >>> You suggest Valve should add the xml-parameter in step 2, but this does >>> not change the behaviour. You don't get any content in step 2, you have to >>> handle it by yourself. >>> >>> >> While you're right there's no actual data coming back in step 2, the URL >> sent back in its place is still wrong, and if they ever change how this >> redirect works and I'm manipulating that URL based on assumptions about the >> current system, my program could break. This is more of a problem with how I >> set up my application (in C#.NET), because if it was just serving the >> profile's XML feed without any redirecting, I could just have an XmlDocument >> load up the feed (the .NET XmlDocument object supports loading a document >> from a URI) and immediately start using the data - instead I'm left to do a >> lot of unnecessary network coding just to make sure I'm getting the right >> document. >> >> -Dave >> >> _______________________________________________ >> 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
