W3C home > Mailing lists > Public > public-xml-processing-model-comments@w3.org > November 2009

RE: Test p:import #006

From: <Toman_Vojtech@emc.com>
Date: Mon, 23 Nov 2009 11:18:03 -0500
Message-ID: <997C307BEB90984EBE935699389EC41C286B56@CORPUSMX70C.corp.emc.com>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 23 November 2009 16:19:33 GMT