Calculating the resource path, was: Deprecating Binding.HTTP

[Jean-Sebastien Delfino <js...@apache.org>]

Jean-Sebastien Delfino wrote:
> Jean-Sebastien Delfino wrote:
>> Luciano Resende wrote:
>>> Binding REST was originally created as a copy of Binding HTTP and it
>>> has been enhanced to a great extent without really removing any of the
>>> native Binding HTTP functionality.
>>>
>>> I was wondering what are people thoughts on deprecating the current
>>> Binding.HTTP, and make the runtime to "proxy" all binding.http to
>>> binding.rest.
>>>
>>> Thoughts ?
>>>
>>
>> Would that work with implementation.widget too? I'm asking because it 
>> looks like Widget components are using binding.http to serve their 
>> resources.
>>
> 
> BTW, that doesn't work so well when Tuscany is running in as Webapp, as 
> the HTTPBindingListenerServlet doesn't get the right resource paths.
> 
> I think that the problem is in HTTPBindingListenerServlet.java:78
> String path = 
> URLDecoder.decode(request.getRequestURI().substring(request.getServletPath().length()), 
> "UTF-8");
> which, I guess, is trying to get the part of the request URI after the 
> http binding servlet path??
> 
> That code seems to work OK in J2SE with an embedded Web container, where 
> there's no Web context root before the servlet path, but gets the wrong 
> part of the URI in a hosted Webapp, where there is a Web context before 
> the servlet path.
> 
> I've tried to replace that line by:
> String path = URLDecoder.decode(request.getPathInfo(), "UTF-8");
> which returned the expected resource path, but I'm not sure what else 
> that change could break.
> 
> Does anybody know for sure the intent of the original code? and why it 
> used getRequestURI() instead of just request.getPathInfo()?
> 
> Thanks

That change doesn't cause any build break, and nobody has come up with 
any more insight, so if there's no objections I'll push it from 
sandbox/sebastien/java/dynamic [1] to trunk.

[1] http://svn.apache.org/repos/asf/tuscany/sandbox/sebastien/java/dynamic/
-- 
Jean-Sebastien

Re: Calculating the resource path, was: Deprecating Binding.HTTP

[Simon Laws <si...@googlemail.com>]

snip...
>>
>> BTW, that doesn't work so well when Tuscany is running in as Webapp, as
>> the HTTPBindingListenerServlet doesn't get the right resource paths.
>>
>> I think that the problem is in HTTPBindingListenerServlet.java:78
>> String path =
>> URLDecoder.decode(request.getRequestURI().substring(request.getServletPath().length()),
>> "UTF-8");
>> which, I guess, is trying to get the part of the request URI after the
>> http binding servlet path??
>>
>> That code seems to work OK in J2SE with an embedded Web container, where
>> there's no Web context root before the servlet path, but gets the wrong part
>> of the URI in a hosted Webapp, where there is a Web context before the
>> servlet path.
>>
>> I've tried to replace that line by:
>> String path = URLDecoder.decode(request.getPathInfo(), "UTF-8");
>> which returned the expected resource path, but I'm not sure what else that
>> change could break.
>>
>> Does anybody know for sure the intent of the original code? and why it
>> used getRequestURI() instead of just request.getPathInfo()?
>>
>> Thanks
>
> That change doesn't cause any build break, and nobody has come up with any
> more insight, so if there's no objections I'll push it from
> sandbox/sebastien/java/dynamic [1] to trunk.
>
> [1] http://svn.apache.org/repos/asf/tuscany/sandbox/sebastien/java/dynamic/
> --
> Jean-Sebastien
>

Looking at the line you reference:

request.getRequestURI().substring(request.getServletPath().length())

It would seem to be trying to get the resource path after the part of
path that identifies the servlet itself. Just by reading the docs your
replacement of this with getPathInfo() seems to be correct.
Description of getPathInfo() at [1] is

"Returns any extra path information associated with the URL the client
sent when it made this request. The extra path information follows the
servlet path but precedes the query string and will start with a "/"
character."

Interestingly looking at the description of getRequestURI() at [1].

"Returns the part of this request's URL from the protocol name up to
the query string in the first line of the HTTP request. The web
container does not decode this String. For example:
First line of HTTP request 	Returned Value
POST /some/path.html HTTP/1.1		/some/path.html
GET http://foo.bar/a.html HTTP/1.0 		/a.html
HEAD /xyz?a=b HTTP/1.1		/xyz "

The example "GET http://foo.bar/a.html HTTP/1.0 		/a.html" doesn't
seem to match the description of being from the protocol name up to
the query string. What do they mean by "protocol name" in this case?

The bottom line is +1 on the change.

Simon

[1] http://www.javadocsonline.com/api/apis/java-ee-sdk6.0.zip/api/javax/servlet/http/HttpServletRequest.html


-- 
Apache Tuscany committer: tuscany.apache.org
Co-author of a book about Tuscany and SCA: tuscanyinaction.com