ContainerMapper/GrizzlyService does not dispatch requests based on keep-alive connection

[glassfishrobot]

Looks like there is a bug in Grizzly layer of GlassFish. Basically, Grizzly layer (ContainerMapper) does not use keep-alive connections to dispatch the requests to the appropriate container. This breaks running any usual (Django or Rails) application on GlassFish when deployed on a non-root context.

Here is what happens:

Application 'myapp' which is a Rails or Django application deployed on GlassFish server, the default context is 'myapp'. This means the application is accessible at http://localhost:8080/myapp. The page rendered by the application has style mentioned as:

<link href="/stylesheets/mystyle.css" media="screen" rel="stylesheet" type="text/css" />

Any web browser while rendering original page (lets say index.html) sends a GET with request, http://localhost:8080/stylesheets/mystyle.css on the same connection (the first request was keep-alive). However GlassFish returns 404 and the rendered page has no style applied. Because ContainerMapper/GrizzlyService uses context-root to look for the Grizzly Adapter the reuquest should be dispatched to.

This is incorrect behavior because the browser has been sending requests with Connection: Keep-Alive, this means ContainerMapper or Grizzly should know which container the request should be dispatched to instead of responding with 404. I am assigning the issue to grizzly-core for further evaluation.

Again here is sequence of events:

user-agent glassfish

---

http://localhost:8080/mysite/ 1. ---------------------------------> Connection: keep-alive

index.html 2. <----------------------------------

http://localhost:8080/stylesheets/mystyle.css 3. ----------------------------------------> Connection: keep-alive

Http Status: 404 4. <---------------------------------------------

Environment

Operating System: All Platform: Macintosh

Affected Versions

[V3]

[glassfishrobot]

• Issue Imported From: https://github.com/javaee/glassfish/issues/9887
• Original Issue Raised By:@glassfishrobot
• Original Issue Assigned To: @yaminikb
• Original Issue Closed By:@glassfishrobot

[glassfishrobot]

@glassfishrobot Commented oleksiys said: Vivek, I'm not sure keep-alive connection let's Grizzly make some assumption about the container, which will process all requests on this connection. AFAIK keep-alive connection doesn't create any contract between client and server, it's just optimization feature. And client is free to use the same TCP connection to make requests to different containers.

[glassfishrobot]

@glassfishrobot Commented jfarcand said: Vivek, I'm not sure I understand the issue. Like Alexey says, the ContainerMapper is not responsible for setting the Connection: Keep-Alive. This is done internally in Grizzly based on the protocol version, and some configuration from domain.xml like max-connections and timeout-in-seconds. The connection is keep alived (internally represented by a SelectionKey) properly, independently of using a ContainerMapper or any Adapter. Now sending:

http://localhost:8080/stylesheets/mystyle.css

is an application error as the browser MUST have send

http://localhost:8080/myapp/stylesheets/mystyle.css

Take any Servlet/JSP and they will works as expected. I do think the <link ...> is wrong.

Another reason is if the browser uses HTTP 1.0, your application will be broken as well. Same when the max-connection is reached and Grizzly close the keep-alived connection. In that case the browser will need to re-connect, and there is no way Grizzly/Container mapper can determine which Adapter the request was previously serviced, as well as the missing context-path (myapp).

[glassfishrobot]

@glassfishrobot Commented vivekp said: Why do such web pages work for servlet applications? I have similar application inside a JSP and it works fine. Not sure why you say that the similar app inside a servlet/jsp will fail the same way.

So the bug really is that ContainerMapper/GrizzlyService should deal all applications (servlet or others) in the same way. How does ContainerMapper/GrizzlyService special case WebContainer?

BTW, brwoser (FF 3.5) is using http 1.1.

[glassfishrobot]

@glassfishrobot Commented jfarcand said: Vivek, there is no special case for WebContainer.

What I wanted to explain here is the <link ...> value is not resolved correctly, and the issue is not from Grizzly/ContainerMapper. The Browser MUST send the proper request with the proper context-path. You example clearly show it doesn't. Note that a Browser can re-use the keep-alived connection for others application, so if the context-path is missing, how the web server can deal with that?

Try to use HTTP 1.0 and you will see it will fail.

[glassfishrobot]

@glassfishrobot Commented Was assigned to oleksiys

[glassfishrobot]

@glassfishrobot Commented This issue was imported from java.net JIRA GLASSFISH-9887

[glassfishrobot]

@glassfishrobot Commented Reported by vivekp

[glassfishrobot]

@glassfishrobot Commented Marked as incomplete on Thursday, October 1st 2009, 12:26:48 am