[
https://issues.apache.org/jira/browse/FELIX-772?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12640472#action_12640472
]
walkerr edited comment on FELIX-772 at 10/17/08 2:18 AM:
------------------------------------------------------------
Further investigation has shed some light on this. Have attached a detailed
narrative below.
It's a tricky and somewhat grey area, My conclusion at this stage is that our
App was relying on a "quirk" of the Jetty4 handling - and that in fact the new
Jetty6 handling is more correct.
The workaround is not too bad either - if an App wants to serve a "default
HTML" page using a request to an alias where the URL carries no resource name
(e.g. http://10.20.0.51:8084/VtWebUi) - there are a few options (which then
mimic the old behaviour):
opt 1 - change the URL that browsers request to include a final "/" e.g.
http://10.20.0.51:8084/VtWebUi/
opt 2 - have the servlet or resource handling return a 302 - which includes the
final "/"
opt 3 - register a "/" alias, and when the VtWebUi request comes in, resolve it
with a 302 redirect, or else just serve the remaining resources based on a "/"
root.
Previous - Jetty4 version:
===================
The "old" Jetty handling for this case seems to send a hidden 302 to redirect
to the alias. I suspect this was down to the way we registered all aliases
under "/" with Jetty itself.
So a URL request to: http://10.20.0.51:8084/VtWebUi for example triggered the
following:
(1) 302 redirect to alias:
GET /VtWebUi HTTP/1.1
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg,
application/x-shockwave-flash, application/xaml+xml,
application/vnd.ms-xpsdocument, application/x-ms-xbap,
application/x-ms-application, application/vnd.ms-excel,
application/vnd.ms-powerpoint, application/msword, */*
Accept-Language: en-gb
UA-CPU: x86
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR
1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30; .NET CLR 3.0.04506.648)
Host: 10.20.0.51:8084
Connection: Keep-Alive
HTTP/1.1 302 Moved Temporarily
Date: Fri, 17 Oct 2008 08:39:53 GMT
Server: Jetty/4.2.x (Windows XP/5.1 x86 java/1.6.0_01)
Location: http://10.20.0.51:8084/VtWebUi/
Transfer-Encoding: chunked
I can only think the 302 happened in Jetty, because our Http servlets and
resources don't do it anywhere)
(2) new request to redirected URL:
GET /VtWebUi/ HTTP/1.1
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg,
application/x-shockwave-flash, application/xaml+xml,
application/vnd.ms-xpsdocument, application/x-ms-xbap,
application/x-ms-application, application/vnd.ms-excel,
application/vnd.ms-powerpoint, application/msword, */*
Accept-Language: en-gb
UA-CPU: x86
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR
1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30; .NET CLR 3.0.04506.648)
Host: 10.20.0.51:8084
Connection: Keep-Alive
HTTP/1.1 200 OK
Date: Fri, 17 Oct 2008 08:39:54 GMT
Server: Jetty/4.2.x (Windows XP/5.1 x86 java/1.6.0_01)
Transfer-Encoding: chunked
Content-Length: 2507
(3) Later resource requests have the alias at the start, and so resolve:
GET /VtWebUi/loading-lg.gif HTTP/1.1
Accept: */*
Referer: http://10.20.0.51:8084/VtWebUi/
Accept-Language: en-gb
UA-CPU: x86
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR
1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30; .NET CLR 3.0.04506.648)
Host: 10.20.0.51:8084
Connection: Keep-Alive
HTTP/1.1 200 OK
Date: Fri, 17 Oct 2008 08:39:55 GMT
Server: Jetty/4.2.x (Windows XP/5.1 x86 java/1.6.0_01)
Transfer-Encoding: chunked
Content-Length: 6848
Content-Type: image/gif
New - Jetty6 version:
================
Alias paths are now actually registered with Jetty itself, altering how they
arrive at getResource() in a way that looks to be "more standard" e.g.
A URL request to: http://10.20.0.51:8084/VtWebUi triggers the following:
(1) URL comes in direct with no 302, and is resolved:
GET /VtWebUi HTTP/1.1
Accept: */*
Accept-Language: en-gb
UA-CPU: x86
Accept-Encoding: gzip, deflate
If-Modified-Since: Tue, 14 Oct 2008 10:12:16 GMT
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR
1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30; .NET CLR 3.0.04506.648)
Host: localhost:8084
Connection: Keep-Alive
Cookie: clickedFolderroot=1%5E2%5E; checkedFolderroot=38%5E38%5E
HTTP/1.1 200 OK
Last-Modified: Fri, 17 Oct 2008 08:26:10 GMT
Content-Length: 2507
Server: Jetty(6.1.x)
This seems correct - a resource request to the alias name on it's own (e.g.
/VtWebUi) should come in with either a "" name.
There isn't a specific example for this case in 102.4 - but it seems a fair
extrapolation of the examples
(2) "relative URL" resources in the HTML then come in without the alias
attached:
GET /loading-lg.gif HTTP/1.1
Accept: */*
Referer: http://localhost:8084/VtWebUi
Accept-Language: en-gb
UA-CPU: x86
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR
1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30; .NET CLR 3.0.04506.648)
Host: localhost:8084
Connection: Keep-Alive
Cookie: clickedFolderroot=1%5E2%5E; checkedFolderroot=38%5E38%5E
HTTP/1.1 404 Not Found
Content-Type: text/html; charset=iso-8859-1
Cache-Control: must-revalidate,no-cache,no-store
Content-Length: 1400
Server: Jetty(6.1.x)
Despite the fact that in our App this breaks with a 404 - I think the
underlying handling is correct.
1 - Our App chooses to return HTML content to the original request.
2 - this "relative path" for this content against the path the alias is mapped
to is "" - so these resource request have no alias pre-prended when they come
in.
It just that point (2) which is niggling me slightly as to whether it's 100%
correct in terms of the intent of OSGi alias handling
was (Author: walkerr):
Further investigation has shed some light on this. Have attached a detaild
narrative below.
It's a tricky and somwehat grey area, My conclusion at this stage is that our
App was relying on a "quirk" of the Jetty4 handling - and that in fact the new
Jetty6 handling is more correct.
The workaround is not too bad either - if an App wants to serve a "default
HTML" page using a request to an alias where the URL carries no resource name
(e.g. http://10.20.0.51:8084/VtWebUi) - there are a few options (which then
mimic the old behaviour):
opt 1 - change the URL that browsers request to include a final "/" e.g.
http://10.20.0.51:8084/VtWebUi/
opt 2 - have the servlet or resource handling return a 302 - which includes the
final "/"
opt 3 - register a "/" alias, and when the VtWebUi request comes in, resolve it
with a 302 redirect, or else just serve the remaining resources based on a "/"
root.
Previous - Jetty4 version:
===================
The "old" Jetty handling for this case seems to send a hidden 302 to redirect
to the alias. I suspect this was down to the way we registered all aliases
under "/" with Jetty itself.
So a URL request to: http://10.20.0.51:8084/VtWebUi for example triggered the
following:
(1) 302 redirect to alias:
GET /VtWebUi HTTP/1.1
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg,
application/x-shockwave-flash, application/xaml+xml,
application/vnd.ms-xpsdocument, application/x-ms-xbap,
application/x-ms-application, application/vnd.ms-excel,
application/vnd.ms-powerpoint, application/msword, */*
Accept-Language: en-gb
UA-CPU: x86
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR
1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30; .NET CLR 3.0.04506.648)
Host: 10.20.0.51:8084
Connection: Keep-Alive
HTTP/1.1 302 Moved Temporarily
Date: Fri, 17 Oct 2008 08:39:53 GMT
Server: Jetty/4.2.x (Windows XP/5.1 x86 java/1.6.0_01)
Location: http://10.20.0.51:8084/VtWebUi/
Transfer-Encoding: chunked
I can only think the 302 happened in Jetty, because our Http servlets and
resources don't do it anywhere)
(2) new request to redirected URL:
GET /VtWebUi/ HTTP/1.1
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg,
application/x-shockwave-flash, application/xaml+xml,
application/vnd.ms-xpsdocument, application/x-ms-xbap,
application/x-ms-application, application/vnd.ms-excel,
application/vnd.ms-powerpoint, application/msword, */*
Accept-Language: en-gb
UA-CPU: x86
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR
1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30; .NET CLR 3.0.04506.648)
Host: 10.20.0.51:8084
Connection: Keep-Alive
HTTP/1.1 200 OK
Date: Fri, 17 Oct 2008 08:39:54 GMT
Server: Jetty/4.2.x (Windows XP/5.1 x86 java/1.6.0_01)
Transfer-Encoding: chunked
Content-Length: 2507
(3) Later resource requests have the alias at the start, and so resolve:
GET /VtWebUi/loading-lg.gif HTTP/1.1
Accept: */*
Referer: http://10.20.0.51:8084/VtWebUi/
Accept-Language: en-gb
UA-CPU: x86
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR
1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30; .NET CLR 3.0.04506.648)
Host: 10.20.0.51:8084
Connection: Keep-Alive
HTTP/1.1 200 OK
Date: Fri, 17 Oct 2008 08:39:55 GMT
Server: Jetty/4.2.x (Windows XP/5.1 x86 java/1.6.0_01)
Transfer-Encoding: chunked
Content-Length: 6848
Content-Type: image/gif
New - Jetty6 version:
================
Alias paths are now actually registered with Jetty itself, altering how they
arrive at getResource() in a way that looks to be "more standard" e.g.
A URL request to: http://10.20.0.51:8084/VtWebUi triggers the following:
(1) URL comes in direct with no 302, and is resolved:
GET /VtWebUi HTTP/1.1
Accept: */*
Accept-Language: en-gb
UA-CPU: x86
Accept-Encoding: gzip, deflate
If-Modified-Since: Tue, 14 Oct 2008 10:12:16 GMT
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR
1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30; .NET CLR 3.0.04506.648)
Host: localhost:8084
Connection: Keep-Alive
Cookie: clickedFolderroot=1%5E2%5E; checkedFolderroot=38%5E38%5E
HTTP/1.1 200 OK
Last-Modified: Fri, 17 Oct 2008 08:26:10 GMT
Content-Length: 2507
Server: Jetty(6.1.x)
This seems correct - a resource request to the alias name on it's own (e.g.
/VtWebUi) should come in with either a "" name.
There isn't a specific example for this case in 102.4 - but it seems a fair
extrapolation of the examples
(2) "relative URL" resources in the HTML then come in without the alias
attached:
GET /loading-lg.gif HTTP/1.1
Accept: */*
Referer: http://localhost:8084/VtWebUi
Accept-Language: en-gb
UA-CPU: x86
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1; .NET CLR
1.1.4322; .NET CLR 2.0.50727; .NET CLR 3.0.04506.30; .NET CLR 3.0.04506.648)
Host: localhost:8084
Connection: Keep-Alive
Cookie: clickedFolderroot=1%5E2%5E; checkedFolderroot=38%5E38%5E
HTTP/1.1 404 Not Found
Content-Type: text/html; charset=iso-8859-1
Cache-Control: must-revalidate,no-cache,no-store
Content-Length: 1400
Server: Jetty(6.1.x)
Despite the fact that in our App this breaks with a 404 - I think the
underlying handling is correct.
1 - Our App chooses to return HTML content to the original request.
2 - this "relative path" for this content against the path the alias is mapped
to is "" - so these resource request have no alias pre-prended when they come
in.
It just that point (2) which is niggling me slightly as to whether it's 100%
correct in terms of the intent of OSGi alias handling
> Resources referenced by local URLs in HTML pages
> ------------------------------------------------
>
> Key: FELIX-772
> URL: https://issues.apache.org/jira/browse/FELIX-772
> Project: Felix
> Issue Type: Bug
> Components: HTTP Service
> Reporter: Rob Walker
> Priority: Minor
>
> The problem below seems to have surfaced in the latest Jetty6 version
> * Register a resource alias e.g.
> srvHttp.registerResources("/VtWebUi, "", myContext);
> * When an empty or / request comes in - e.g. rhttp://localhost:8084:/VtWebUi
> - have the resource context resolve these to return an HTML page such as an
> entry page e.g.
> public URL getResource(String name)
> {
> if (name.equals("/") || name.length() == 0)
> {
> name = "/VtWebUi.html";
> }
> ....
> * Subsequent "relative" URL resource references (or at least some of them)
> fail to be found> This is because they in with a path of /local-resource,
> rather than prefixed with the alias e.g. /VtWebUi/local-resource, and hence
> don't get routed to the resource context to resolve them
> * A fully expanded request for the HTML page will work fine e.g.
> http://localhost:8084/VtWebUi/VtWebUi.html . Again, this is because the
> relative URLs for embedded resources come in with the /VtWebUi prefix needed
> for alias matching
> Note: The issue may be a local issue with our application / and the way we
> use GWT.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
