On 7 December 2010 14:58, Oleg Kalnichevski <[email protected]> wrote: > On Tue, 2010-12-07 at 12:48 +0000, sebb wrote: >> On 7 December 2010 09:35, Oleg Kalnichevski <[email protected]> wrote: > > ... > >> > Hi Sebastian >> > >> > I could find any passage in javadocs or tutorial stating such >> > requirement. >> >> Javadoc for getURI() starts: >> >> /** >> * Returns the URI this request uses, such as >> * <code>http://example.org/path/to/file</code>. >> * >> >> which strongly suggests that the URI is absolute. >> > > Honestly, I fail to see a strong suggestion here. The URI used as an > example just happen to be absolute. That is it.
Well, "/path/to/file" makes no sense on its own as a request URI. However the HttpUriRequest interface does not have any methods for returning the host or scheme. >> Also, section 1.1.1 has 2 examples which display absolute URIs. >> > > Again, to me that does not have any implications other than two examples > happen to use absolute URIs. > >> I've not found an example which shows a relative URI. >> >> > As far as I remember request URIs can be either absolute or >> > relative. >> >> AFAICT, this is not documented. >> > > http://download.oracle.com/javase/1.4.2/docs/api/java/net/URI.html Sorry, I meant URIs returned by getURI() are not documented as being relative or absolute. > >> Seems to me that user code is often going to need the absolute URI of >> the request, so there should be a method to return the absolute URI. >> >> It's confusing that the URI returned from the execution context >> appears to be always relative, even if the original request uses an >> absolute URI. >> > > The final HttpRequest object in the execution context always represents > the state of the message _exactly_ as it was sent to the target server. > Per default HTTP/1.0 and HTTP/1.1 use relative request URIs. OK, this is worth documenting. > If you feel that the javadocs need to be more specific / clear / > unambiguous, by all of means just go ahead and improve them. Will do. > Cheers > > Oleg > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
