On 29.06.2011 13:55, Konstantin Kolinko wrote: > 2011/6/29 Rainer Jung <rainer.j...@kippdata.de>: >> Motivated by >> >> https://issues.apache.org/jira/browse/WICKET-3841 >> >> I tested response.encodeURL("http://localhost:8080";) and I get >> http://localhost:8080;jsessionid=... (cookies off). >> >> Note that there is no slash between the port and the sessionid path info. >> >> According to my reading of RFC3986 (URIs), the input URI is a correct >> URI, the resulting URI is not: because it has an authority, the rest >> must be zero or more path-abempty, which always start with a slash. >> >> Did anyone stumble over this yet? If there's no objections, I'll write a >> patch and check, what the TCK has to say. >> >> The spec does not see to contain any specification of encodeURL apart >> from the JavaDoc. >> > > From RFC3986 alone I agree that > 1) http://localhost:8080 > looks like a valid URL by RFC3986. > (like any other URL without a trailing slash, e.g. mailto:) > > From HTTP standpoint it should be http://localhost:8080/ and in my > experience browsers add the trailing slash automatically. I have not > looked whether the actual HTTP spec is more strict regarding such > URLs. > > 2) http://localhost:8080;jsessionid=... > is an invalid URL. > > I am +1 to use "/" as the path if it is an absolute URL, scheme is > http or https and the path is empty. (I guess that there is a check > for the scheme name already?).
If the URI doesn't point to the application itself, encodeURL() doesn't change the URL. This is especially true, for any non-http(s) scheme. > So that it becomes > http://localhost:8080/;jsessionid=... Implemented in r1142959. Now the next question is about encodeRedirectURL(). It behaves like encodeURL() except it doesn't fix empty URLs ("") and does not yet have the empty path fix. This difference seems to go back long in time (I checked back until 2003). Should we keep this difference (don't fix if it ain't broken), or should encodeRedirectURL() behave exactly the same as encodeURL()? Regards, Rainer --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
