- From: <Toman_Vojtech@emc.com>
- Date: Mon, 23 Nov 2009 11:18:03 -0500
- To: <public-xml-processing-model-comments@w3.org>
Norm, Are you sure? If you use a Java library like Apache HttpClient, you can do something like this: HttpMethod method = ...; new HttpClient().executeMethod(method); URI resolvedURI = method.getURI(); If you run the code above, the value of resolvedURI will point to the *final location* of where the connection resolved to. This is what we do in our implementation and it seems to work just fine. Regards, Vojtech > -----Original Message----- > From: public-xml-processing-model-comments-request@w3.org > [mailto:public-xml-processing-model-comments-request@w3.org] > On Behalf Of Norman Walsh > Sent: Monday, November 23, 2009 4:39 PM > To: public-xml-processing-model-comments@w3.org > Subject: Re: Test p:import #006 > > Hello world, > > I've done a little more investigation and I think import-006 places an > unreasonable burden on implementors. AFAICT, the only way to get this > right is to manage all of the HTTP redirections "by hand". In the Java > case, that means building an explicit HttpURLConnection, disabling > "follow redirects", and then rebuilding the follow redirects logic > locally, keeping track of where the redirection occurs. > > Unless I'm mistaken (and I'm happy to be told that I am), you can't > tell from a URLConnection, or even from an HttpURLConnection if follow > redirects is enabled, where the final connection was resolved. > > Be seeing you, > norm > > -- > Norman Walsh <ndw@nwalsh.com> | It is important to realize that any > http://nwalsh.com/ | lock can be picked with a big enough > | hammer. >
Received on Monday, 23 November 2009 16:19:32 UTC