<< Back to previous view

[SERVLET_SPEC-79] As of Servlet 3.0, there is no way to create code guaranteed to run first before anything else Created: 31/Aug/13  Updated: 09/Oct/13

Status: Open
Project: servlet-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Critical
Reporter: Nick Williams Assignee: Rajiv Mordani
Resolution: Unresolved Votes: 1
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: servlet-container-initializer web-fragment order
Participants: dokovski, markt_asf, Nick Williams and Rajiv Mordani

 Description   

In Servlet 2.5 and earlier, if you needed code that you could guarantee would always run first, you implemented ServletContextListener, put your important code in the initialization method, and defined it as the very first listener in your deployment descriptor web.xml. This was critically important for many tasks, such as logging initialization. Logging initialization typically must happen before anything else, or else it could be initialized incorrectly.

Servlet 3.0 added the awesome and useful concept of the ServletContainerInitializer, but this introduced a critical problem. There is no longer any way to create code guaranteed to run before anything else. First, a ServletContainerInitializer will always run before any ServletContextListener is initialized, so you can't rely on a ServletContextListener to run your critical startup code. I thought that a ServletContainerInitializer would run in the order of its web-fragment (either <order> in web-fragment.xml or <absolute-ordering> in web.xml), but I was wrong. The spec makes no such guarantee. Initializers are guaranteed nothing more than a random execution order. Because of this, it is impossible to guarantee that critical startup code will always run first.

Some containers appear to abide by the web-fragment order any. For example, Tomcat, TomEE, and JBoss definitely order initializers according to their web-fragment order (this is confirmed in code), while WebLogic and WebSphere appear to order them the same way (they are closed source, so this can't be completely confirmed, but the behavior is consistent). However, GlassFish, Jetty, and Resin order initializers in the order they are returned from the ClassLoader.

The execution of an ServletContainerInitializer should be ordered according to its web-fragment order. Alternatively a separate ordering mechanism could be specified, but this would seem to be unnecessary and burdensome. Furthermore, I think the committee should encourage (though obviously it cannot require) existing 3.0 and 3.1 implementations to apply this change retroactively, since it doesn't change the API.

Failing to require a predictable and controllable order for initializers is a serious oversight in the spec and represents a regression from 2.5, where it was possible to write code guaranteed to always run first.



 Comments   
Comment by markt_asf [ 19/Sep/13 11:22 AM ]

There are some further complicating factors here:
1. Ordering of container provided SCIs vs application provided SCIs
2. Ordering when the container and the application both provide an implementation of an SCI
2a. The application provided implementation may be disabled via ordering
2b. Delegation order determines which implementation (container or application) takes precedence when loading.

I suggest the following approach.

1. Container provided SCIs are always executed first in a container determined order.
a. If an application provides an alternative implementation then that is used at this point
regardless of exclusion via ordering
2. Application provided SCIs are executed in fragment order

Comment by dokovski [ 19/Sep/13 11:37 AM ]

In relation to 1a:
Does this mean that if an app has bundled web library that uses the SCI mechanism this library takes precedence over platform supplied ones? There is a recommendation in Java EE specification EE 8.2.3 Library Conflicts:
In particular:"Note that if the library is also a required component of the Java EE platform version on which the application is being deployed, the platform version may (and typically will) take precedence."

Comment by markt_asf [ 19/Sep/13 11:58 AM ]

Re 1a it actually depends on the configured delegation order (see Servlet 3.0/3.1 section 8.2 final paragraph). The point I was trying to make is if the container defines an SCI then it is loaded with the other SCIs even if it is loaded from the application. For this to happen:

  • the application would have to ship an SCI implementation that the container also defined
  • the container / application would have to configured with an application first class loading delegation order.

The aim is that all container specified SCIs are loaded first even if the implementations of some of them are provided by the application because the application ships with an alternative implementation.





[SERVLET_SPEC-1] Improve HttpSession distribution semantics Created: 31/May/11  Updated: 08/Jan/13

Status: Open
Project: servlet-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: gregwilkins Assignee: Rajiv Mordani
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: FUTURE_RELEASE
Participants: gregwilkins, markt_asf and Rajiv Mordani

 Description   

Currently there are significant ambiguities in the servlet specification with regards to how sessions should be distributed:

+ should changes made to the attibute value objects after the setAttribute be reflected in the persisted/distributed state? Is setAttribute pass-by-reference or pass-by-value ?

+ when is a session attribute persisted/distributed? When setAttribute is called? when the current request completes? when all simultaneous requests complete? at regular intervals? on container shutdown?

+ the requirement that only a single instance of a session is active in a cluster is difficult to efficiently implement. Can concurrent instances be allowed?

+ are sessions persisted/serialized attribute by attribute or as a single session blob?



 Comments   
Comment by markt_asf [ 01/Jun/11 04:15 AM ]

Some additional questions related to distributed sessions:

+ When a session is distributed across multiple container instances, how should listeners be notified of HTTP session events? Only those listeners on the 'active' instance where the change originated, all instances, something else?

+ In the above case, should the listener notification behaviour be configurable, if so how and at what level (container, context, session, listener, something else)?

Comment by Rajiv Mordani [ 12/Dec/12 07:47 AM ]

In general so far Java EE platform does not talk about distributed semantics / HA behavior of containers. These features are left up to the container vendors to implement and make available. If we were to put details around distributed servlet programming model it would have to go beyond just HttpSession. At this time I am inclined to wait and see what we plan to do for Java EE platform as a whole before attempting to define distributed session semantics.

Comment by Rajiv Mordani [ 08/Jan/13 11:06 PM ]

Adding it to the bucket of FUTURE_RELEASE





[SERVLET_SPEC-2] Pluggable resource loaders Created: 14/Jun/11  Updated: 05/Feb/13

Status: Open
Project: servlet-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Major
Reporter: Eirik Bjørsnøs Assignee: Rajiv Mordani
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

File Attachments: Zip Archive resourceloader-poc-2011-12-15.zip     Text File SERVLET_SPEC_2-2011-12-11.patch     Text File SERVLET_SPEC_2_JETTY_8_2011-12-15.patch     Text File SERVLET_SPEC_2_JETTY_servlet-spec_2011-12-15.patch    
Tags: future_release
Participants: Eirik Bjørsnøs and Rajiv Mordani

 Description   

While the pluggability support in Servlet 3.0 was a great improvement, I do still find it to be a somewhat limited. In 3.0, all resources have to be bundled inside META-INF/resources in a jar in WEB-INF/lib in the deployed war. I think this is a bit rigid and that we would benefit from adding more flexibility in how resources can be loaded.

I suggest adding a provider interface to the servlet API which will allow implementors to load resources from arbitrary locations. That could be the file system, the network, OSGi bundles, the classpath, some generated in-memory representation or any other source which can locate and load resources.

How would this be useful? Our particular use case is to support plugin based architectures on the Servlet/JSP platform. For these kinds of applications, it it desirable to distribute apps and plugins independently. It is inconvenient having to reassemble the application war file just to add or upgrade a plugin. It should be possible to add it simply by dropping it in a folder. In the same way, would like to add and remove plugins at runtime. Both of these requirements are impossible to implement with Servlet 3.0, but should be easy to implement with the proposed API.

Other use cases that comes to mind might be: sharing of resources across contexts, loading resources from source during development and being able to separate downloadable application data from the application itself.

Also note that the current Servlet 3.0 way of loading resources from /META-INF/resources on the classpath could be implemented as a resource loader in the suggested design. Likewise, the normal resource loading from the war file could also be modeled as a resource loader. So in a way, we already have multiple ways of loading resources, we just don't have a well defined name and concept around it that people can use.  (Or rather framework developers, I don't see this as something the average developer will commonly have to deal with directly, they'll probably use a framework/library which supports it)

For the purpose of discussion, I'll throw out an initial design idea here:

-----------------------------------------------

  • New interface ResourceLoader:

package javax.servlet.ResourceLoader;

interface ResourceLoader {  URL getResource(String path);  Set getResourcePaths(String path);  InputStream getResourceAsStream(String path); }

(The methods will behave similar to their cousins in javax.servlet.ServletContext, just being scoped to a single ResourceLoader. "path" is the path being looked up.)

  • New method addResourceLoader(ResourceLoader resourceLoader) in javax.servlet.ServletContext which will register a ResourceLoader for use in the servlet context.
  • New web.xml / web-fragment.xml syntax:

<resource-loader>
   <resource-loader-class>com.example.MyResourceLoader</resource-loader-class>
</resource-loader>

  • Change javax.servlet.ServletContext methods getResource, getResourcePaths and getResourceAsStream to consider registered resource loaders in addition to the resources found in the war and in META-INF/resources. Resource loaders would be consulted in the order of their registration.

I'm very interested in hearing objections, ideas for alternative/improved/simpler designs, security concerns or other considerations. There's probably no shortage of things I haven't thought about



 Comments   
Comment by Eirik Bjørsnøs [ 14/Jun/11 02:49 AM ]

Discussion on users@servlet-spec.java.net :

http://java.net/projects/servlet-spec/lists/users/archive/2011-06/thread/1

Comment by Eirik Bjørsnøs [ 23/Jun/11 06:42 AM ]

I now have a working implementation of this based on Glassfish trunk.

I'll upload a patch, but I need to review the code and do some more testing first.

For now, here's a summary of changes/additions made:

------------
M deployment/schemas/src/main/resources/glassfish/lib/schemas/javaee_6.xsd
M deployment/schemas/src/main/resources/glassfish/lib/schemas/web-common_3_0.xsd

Added support for new XML syntax <resource-loader><resource-loader-class>com.example..</resource-loader-class></resource-loader>

(I know these will need to be moved to the 3.1 / jeee7 versions of these files, but I decided not to do that now after a few failed attempts.

------------
A + deployment/dol/src/main/java/com/sun/enterprise/deployment/node/web/ResourceLoaderNode.java
M deployment/dol/src/main/java/com/sun/enterprise/deployment/node/web/WebCommonNode.java
M deployment/dol/src/main/java/com/sun/enterprise/deployment/node/DescriptorFactory.java
A + deployment/dol/src/main/java/com/sun/enterprise/deployment/AppResourceLoaderDescriptorImpl.java
A + deployment/dol/src/main/java/com/sun/enterprise/deployment/web/AppResourceLoaderDescriptor.java
M deployment/dol/src/main/java/com/sun/enterprise/deployment/WebBundleDescriptor.java
M deployment/dol/src/main/java/com/sun/enterprise/deployment/xml/WebTagNames.java

Changes related to parsing the new <resource-loader> and <resource-loader-class> nodes and representing them as an AppResourceLoaderDescriptor. I pretty much stole the code from <listener> since they're structurally the same.

------------
M web/javax.servlet/src/main/java/javax/servlet/ServletContext.java
A web/javax.servlet/src/main/java/javax/servlet/ResourceLoader.java

Added the ResourceLoader interface and ServletContext.addResourceLoader.

------------
M web/web-core/src/main/java/org/apache/catalina/core/StandardContext.java
M web/web-core/src/main/java/org/apache/catalina/core/ApplicationContext.java
M web/web-core/src/main/java/org/apache/catalina/core/ApplicationContextFacade.java
M web/web-core/src/main/java/org/apache/catalina/servlets/DefaultServlet.java
M web/web-core/src/main/java/org/apache/catalina/Context.java
M web/web-core/src/main/resources/org/apache/catalina/core/LocalStrings.properties

  • Added support for adding resource loaders, programmatically or from a class name given via XML
  • Consult resource loaders when looking up resources in ServletContext's getResource*, getRealPath methods.
  • Consult resource loaders when serving resources in DefaultServlet.serveResource

------------
M web/web-glue/src/main/java/com/sun/enterprise/web/TomcatDeploymentConfig.java

Register the context's resource loaders by using the information available in AppResourceLoaderDescriptor

Comment by Eirik Bjørsnøs [ 23/Jun/11 06:48 AM ]

When adding support for resource loaders to DefaultServlet, I found the serveResource method to be hard to work with.

I've filed an issue in the Glassfish Jira for this, with some suggestions for improvements:

http://java.net/jira/browse/GLASSFISH-16871

Comment by Eirik Bjørsnøs [ 11/Dec/11 10:37 PM ]

Patch includes API changes to the Servlet spec and a working Glassfish implementation of the changes

Comment by Eirik Bjørsnøs [ 12/Dec/11 10:09 PM ]

Demo web application project. The webapp tests that the container implements resourceloader according to the specification.

The project also includes a demo of hot deployment of JSPs from OSGi bundles.

Comment by Eirik Bjørsnøs [ 12/Dec/11 10:33 PM ]

Including post to user list for reference:

Thinking about it, my resource loader proposal for Servlet 3.1 might
have a multi-tenancy story as well as a dynamic deployment story.

I initially focused on a single tenant being able to dynamically
(hot)deploy resources. However, being able to define custom resource
loaders will also enable resource sharing across multiple tenants
without having to use container specific hacks or custom builds of
webapps.

I've uploaded a patch to the Jira issue which adds the ResourceLoader
interface and the ServletContext.addResourceLoader method. The patch
also includes a working implementation of resource loader support in
Glassfish trunk.

Finally, I've also uploaded a proof-of-concept web application. This
application tests the container's implementation of the ResourceLoader
API. And just for fun, I threw in a ResourceLoader backed by OSGi
bundles using Apache Felix.

Comment by Eirik Bjørsnøs [ 15/Dec/11 02:49 PM ]

Updated poc with improved tests and getResourcePaths() implementation for OSGi

Comment by Eirik Bjørsnøs [ 15/Dec/11 04:41 PM ]

Patch implementing ResourceLoader support for Jetty 8

Comment by Eirik Bjørsnøs [ 15/Dec/11 04:44 PM ]

Updates to Jetty's 3.0 Servlet Spec module adding ResourceLoader





[SERVLET_SPEC-7] Clarify expected behviour of fitlers and welcome files Created: 25/Aug/11  Updated: 09/Jan/13

Status: In Progress
Project: servlet-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: markt_asf Assignee: Rajiv Mordani
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: markt_asf, Rajiv Mordani and rojkov

 Description   

The specification is not explicit regarding the order of welcome file processing and filter mapping. This has caused limited user confusion.

My own expectation is that welcome files are processed first and then filter mappings. Previous conversations with Servlet 3.0 EG members confirmed this. It would be help to get a short note of this added to the Servlet 3.1 spec.



 Comments   
Comment by rojkov [ 07/Dec/11 02:41 AM ]

I am not sure I understand. Can I still a filter request to a welcome file with the proposed change?

Comment by markt_asf [ 07/Dec/11 06:01 PM ]

OK. Here is some additional clarification.

If a user requests "/foo" and "/foo" is a directory, the welcome files "index.jsp" and "index.html" are configured and "index.html" is present then what is compared against the filter mappings. Is it "/foo" or "/foo/index.html"

The clarification I previously received from the Servlet 3.0 EG is that is is "/foo/index.html" that is compared against the filter mappings. It is this clarification I would like to see in the 3.1 spec.

Comment by Rajiv Mordani [ 28/Jun/12 07:47 PM ]

Sounds reasonable to me - one question is what happens in the case of the DefaultServlet being invoked in the case where we don't have a welcome file? Should it then be that the filter is applied to /foo or not? I will start a thread on this in the EG.

Comment by Rajiv Mordani [ 09/Jan/13 01:11 AM ]

Mark I went back and looked at the discussion in the 3.0 and am including some of that here -

My colleague Shing Wai Chan pointed out that the proposed solution is
somewhat unsatisfactory in the sense that it still might be possible
to receive a 404 response when honoring one welcome page even if the
next welcome page in the list would have produced a valid result.

Consider a slight variation of Greg's original example, where
"index.html" is replaced with "foo.bar" in the list of welcome page
declarations:

index.jsp
foo.bar

Further assume that:

  • a servlet mapping (to the "FooBar" servlet) exists for "*.bar",
  • neither index.jsp nor foo.bar exist as file resources, and
  • the FooBar servlet does not depend on foo.bar in order to produce
    its response

The proposed new algorithm would not find any matching static
resources when enumerating the welcome page declarations during the
first round, but would honor the servlet mapping for index.jsp when
enumerating the welcome page declarations in the 2nd round, leading to
a 404, even if skipping "index.jsp" and picking "foo.bar" instead
would have produced a valid response.

I guess there is nothing we can do to help in this case. It would be
nice if it were possible to specify (in a welcome declaration) whether
the welcome page needs to exist as an actual file resource in order
for its mapped-to servlet to be able to produce a response, but the
current syntax for <welcome-file-list> would make this hard if not
impossible.

Comments?

Jan

and Greg's response to that was -

Jan,

I think this is indeed a problem, but I don't think there is much we can
do to fix it without changing the web.xml.

There is a fundamental problem of mixing the search semantics that
can be done on files with dispatching to servlets, which don't
support search semantics.

I think that the current compromise is the best we can do if we
wish to continue allow servlets to be welcome-files even when
the no file exists.

Given that even appending the files may not work, I think we can't really fix it the way you are suggesting.

Comment by markt_asf [ 09/Jan/13 09:01 PM ]

I think in the case of the default servlet returning a 404 then the filter should be applied if url-pattern matches whatever url the default servlet is returning a 404 for.

Regarding the the issues described in the extract of the Servlet 3.0 discussion I think that is a slightly different issue. In Tomcat we introduced a list of "resource only servlets" which essentially only get mapped to welcome files if a file resource (e.g. a JSP) exists at that URL. I do wonder if that container specific solution could be generalised (e.g by a new attribute on Servlet) but that is a discussion for a different issue / the mailing list.





[SERVLET_SPEC-9] Make web.xml accessible prior to ServletContext initialisation Created: 06/Sep/11  Updated: 22/Feb/13

Status: Open
Project: servlet-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Major
Reporter: bleathem Assignee: Shing Wai Chan
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: FUTURE_RELEASE
Participants: bleathem, rojkov and Shing Wai Chan

 Description   

It would be useful if one could access the contents of the web.xml file, prior to the ServletContext being available.

A use case for this is in writing CDI extensions, where it would be useful to access web.xml configuration data. Currently this is not possible to achieve in a portable way, as the ServletContext has not yet started, and is not available to CDI extensions (in EE environments at least).

Since the WEB-INF folder is not on the classpath, using the context ClassLoader is not possible. Perhaps the solution to this is as simple as adding the WEB-INF folder to the application classpath?



 Comments   
Comment by rojkov [ 07/Dec/11 02:38 AM ]

I think this needs a use case. I can't not suggest that parsing web.xml yet another time should be avoided. Possibly, we can define a pre-start phase that makes the xml available in parsed state.

Comment by bleathem [ 07/Dec/11 07:38 AM ]

A use case is as I stated in the issue description, where one wants to access the web.xml from a CDI extension. For instance, to determine the JSF project stage, to conditionally activate different beans in production and development.

Comment by Shing Wai Chan [ 08/Jan/13 10:18 PM ]

At this time, we don't expose the content of web.xml in Servlet API.
Where do you want to access the information contained in the descriptor and how can we reconcile the information specified by annotation?
It will be consider in the future release.

Comment by Shing Wai Chan [ 22/Feb/13 10:28 PM ]

Adding it to the bucket of FUTURE_RELEASE





[SERVLET_SPEC-11] Clarification required for ServletContext.getRealPath and HttpServletRequest.getPathTranslated Created: 21/Sep/11  Updated: 29/Jun/12

Status: In Progress
Project: servlet-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: markt_asf Assignee: Rajiv Mordani
Resolution: Unresolved Votes: 1
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: gregwilkins, markt_asf and Rajiv Mordani

 Description   

There appear to be different interpretations of the required behaviour of ServletContext.getRealPath(java.lang.String path) and HttpServletRequest.getPathTranslated() if the virtual path can be mapped to a physical path but the physical path does not exist.

My reading of the specification and the Javadoc is that the physical path does not have to exist, just that the mapping has to be possible. However, I can see how someone else could read the specification as requiring the physical path to exist and null to be returned if it does not.

This should be clarified for Servlet 3.1 and ideally the clarification included in any subsequent maintenance releases of the earlier specification versions.



 Comments   
Comment by gregwilkins [ 23/Sep/11 05:01 AM ]

I think the text should be changed to indicate that a path should be returned if it possibly could exist.

Typically this would mean that if getRealPath("/") returns a non null path, then all calls to getRealPath should not be null.

Comment by Rajiv Mordani [ 28/Jun/12 09:05 PM ]

In section 3.6 of the spec we clearly say

In situations where the servlet container cannot determine a valid file path for these methods, such as when the Web application is executed from an archive, on a remote file system not accessible locally, or in a database, these methods must return null. Resources inside the META-INF/resources directory of JAR file must be considered only if the container has unpacked them from their containing JAR file when a call to getRealPath() is made, and in this case MUST return the unpacked location.

and the javadocs also says along the same lines. What do you think will make it clearer?

Comment by markt_asf [ 28/Jun/12 10:26 PM ]

If memory serves me correctly this wasn't a WAR/database/virtual vs local filesystem issue. If was purely in the context of a local file system when everything is unpacked.

Take, for example, a WAR with context path "/foo" unpacked on the local file system to "/usr/local/webapps/foo".

Assume that there also exists the directory "/usr/local/webapps/foo/bar"

When called from the "foo" web application, getRealPath("/bar") will return "/usr/local/webapps/foo/bar".

The question is, what should getRealPath("/other") return?

Should it:
a) return "/usr/local/webapps/foo/other" since that what it maps too?
b) return null since "/usr/local/webapps/foo/other" does not exist?

This really boils down to what does the specification mean by valid in section 3.6? I think we need to make it clear that "valid" does not mean "must exist".

I've dug through the archives and the Tomcat bug that prompted this request for clarification was this one: https://issues.apache.org/bugzilla/show_bug.cgi?id=51799

Comment by Rajiv Mordani [ 29/Jun/12 07:13 AM ]

The getRealPath should return the real paths for resources that are available. So to be specific - in the example above if "other" does not exist in the webapp then it should return null. Looking at the issue filed for tomcat, Remy seems to suggest that it return the path so it is possible to create a file / directory using it. We can discuss this in the EG.





[SERVLET_SPEC-12] Clarify the path prefix mapping in Section 12.1 Created: 21/Sep/11  Updated: 06/Feb/13

Status: Open
Project: servlet-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: Santiago Pericas-Geertsen Assignee: Rajiv Mordani
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: extension future_release mapping matching path prefix servlet
Participants: gregwilkins, Rajiv Mordani and Santiago Pericas-Geertsen

 Description   

Section 12.1 states that prefix mapping is done by stepping down the path tree on directory at a time. However, given a path "/foo/", it does not mention how to deal with the trailing "/". This is significant given that "/foo" (no trailing slash) matches "/foo/" as shown later in that chapter (which is a bit confusing if "/" is naively converted in to a regexp).

The use of "/" with the intended semantics is somewhat misleading since it can match any number of paths, including zero. Ant uses "*" to match arbitrary number of directories (including none). IMO, a better syntax for servlet mapping would be:

/.../* => /.../** (path prefix)
(ii) .ext => //.ext (extension mapping)

For example,

(1) match(/a/**, /a/b/c/d) = (/a, /b/c/d)
(2) match(/a/**, /a) = (/a, null) (since ** matches 0 directories)

and

(3) match(/*/.ext, /a/b/c.ext) = (/a/b/c.ext, null)

Changing the syntax would obviously be backward incompatible, but perhaps an alternate syntax could be consider in future revisions of the spec.



 Comments   
Comment by gregwilkins [ 23/Sep/11 04:58 AM ]

While I agree that the path mapping is a bit strange, I'm loath to change it now.... unless there is significant support to do so.

If there is to be a change in the mapping, then another issue that needs to be fixed is the inability to form a pattern to match the ROOT of a webapp, since "/" is the default mapping. Also the fact that "/" has different semantics to "/*" is confusing as they both match the same requests (in the absence of any suffix matches).





[SERVLET_SPEC-16] Add the ability to set <jsp-file> though the ServletRegistration interface Created: 04/Oct/11  Updated: 07/Feb/13

Status: Open
Project: servlet-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: markt_asf Assignee: Rajiv Mordani
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: markt_asf and Rajiv Mordani

 Description   

Title says it all. This looks like an oversight in the original ServletRegistration API.



 Comments   
Comment by Rajiv Mordani [ 07/Feb/13 08:21 AM ]

Not everything defined in the web.xml can be done via ServletRegistration.

Comment by markt_asf [ 07/Feb/13 08:28 AM ]

Indeed, but is there a reason not to add jsp-file that I have missed?

Comment by Rajiv Mordani [ 07/Feb/13 08:55 AM ]

There was no specific discussion about jsp-file, however the main goal of the APIs for adding Servlet, Filters and Listeners was for pluggability of frameworks. Not sure how many frameworks will really need to the jsp-file for pluggability.

Comment by markt_asf [ 07/Feb/13 09:01 AM ]

Here is the Tomcat discussion that triggered this request:
http://tomcat.markmail.org/thread/pg65fgqhfra7czy5





[SERVLET_SPEC-18] Clarify behaviour of getRequestURI(), getContextPath(), getServletPath() and getPathInfo() Created: 07/Oct/11  Updated: 06/Dec/11

Status: Open
Project: servlet-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: markt_asf Assignee: Rajiv Mordani
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: markt_asf and Rajiv Mordani

 Description   

The specification is unclear for some or all of the above methods how the following should be handled.

  • path parameters - should they be included in the returned values or not?
  • normalisation - should the returned values be pre- or -post any normalisation?
  • url decoding - should the returned values be decoded or include the escapes?
  • character encoding - if a value is decoded, what character encoding should be used?
  • welcome files - if a request maps to a welcome file, should it be included in the return values?


 Comments   
Comment by markt_asf [ 11/Oct/11 11:40 AM ]

Add getRequestURI() to the methods to be reviewed





[SERVLET_SPEC-20] Clarify implicit mappings and welcome file behaviour Created: 07/Oct/11  Updated: 06/Dec/11

Status: Open
Project: servlet-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: markt_asf Assignee: Rajiv Mordani
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: gregwilkins, markt_asf and Rajiv Mordani

 Description   

Consider the following:
*.do is mapped to a servlet
welcome files are index.jsp, index.do

The intention is that the index.jsp page should be used if present and index.do (which always maps to the servlet) used if it is not. However, a strict reading of the servlet spec requires that a 404 is returned in index.jsp is not present .



 Comments   
Comment by gregwilkins [ 10/Oct/11 02:02 AM ]

The problem with this mechanism is that it was designed (and named) for welcome files. This has been somewhat subverted to allow for welcome servlets - ie if *.jsp is mapped to a servlet, then you get this 404 issue.

I believe the solution is to have a separate welcome servlet configuration, that would allow index.do to be attempted even though there is not a index.do file that exists.





[SERVLET_SPEC-21] Clarify behaviour with pre-emptive authentication Created: 07/Oct/11  Updated: 12/Feb/13

Status: Open
Project: servlet-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: markt_asf Assignee: Shing Wai Chan
Resolution: Unresolved Votes: 1
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: arjan tijms, markt_asf, monzillo and Shing Wai Chan

 Description   

The HTTP spec allows pre-emptive authentication - i.e. sending credentials before the server asks for them. It is unclear from the Servlet spec how getRemoteUser() and friends should behave in this regard when the resource being requested does not require authentication. Should the credentials be processed or ignored?



 Comments   
Comment by markt_asf [ 07/Oct/11 01:37 AM ]

Note: pre-emptive authentication can never work with DIGEST auth

Comment by monzillo [ 10/Jan/13 06:46 PM ]

imv, we should apply an established authentication session when we access
an unprotected resource within the session; that is, assuming the authentication session
conforms to the session mechanism configured for the application. iirc, the spec is not
clear on that, and it could be worth adding that as a requirement.

Regarding the processing of authenticators included in requests to unconstrained resources, I think such authenticators should be ignored during constraint processing (for the required to be supported authentication mechanism processors). Conversely they should be processed if the target resource makes a call to HttpServletRequest.authenticate.

That said, I think we should allow custom authentication mechanisms to decide how they will treat authenticators sent to unprotected resources. In the servlet profile of jsr 196, the the configured authentication system is called on every request, leaving it up to it, to decide whether or not to process a received authenticator.

Comment by arjan tijms [ 09/Feb/13 08:04 PM ]

In the servlet profile of jsr 196, the configured authentication system is called on every request, leaving it up to it, to decide whether or not to process a received authenticator.

Ron, is this tested in the TCK? At least JBoss EAP and AS don't do this at all, yet they are certified for Java EE 6.

Comment by arjan tijms [ 11/Feb/13 11:01 PM ]

Doing some more digging in the JBoss code, I found an optional "valve" (it's not documented), via which JBoss EAP/AS do process unprotected resources as well. It has an interesting comment:

/**
 * <p>
 * This class implements a JASPI authenticator for unprotected resources. In the JASPI Servlet profile, authentication
 * for unprotected resources is optional but it is still allowed. When performed, the JASPI authentication modules must
 * grant access to the unprotected resources irrespective of the caller, which may be anonymous (i.e, no security info
 * supplied).
 * </p>
 *
 * @author <a href="mailto:sguilhen@redhat.com">Stefan Guilhen</a>
 */
@SuppressWarnings("unused")
public class WebJASPIOptionalAuthenticator extends ValveBase {

(see http://grepcode.com/file/repo1.maven.org/maven2/org.jboss.as/jboss-as-web/7.1.2.Final/org/jboss/as/web/security/jaspi/WebJASPIOptionalAuthenticator.java#WebJASPIOptionalAuthenticator)

I couldn't really find a spec reference that says authentication for unprotected resources is optional.

Comment by monzillo [ 11/Feb/13 11:24 PM ]

Arjan, You are correct that the Servlet profile of jsrs 196 requires that ServerAuthContex#validateRequest be called on every request that satisfies the connection requirements (i.e., any user-data-constraint). Other than the above exception this includes all request urls independent of whether the resource would have been authorized prior to the the call to ValidateRequest. That said, once the validateRequest is called, the authentication module is expected to behave differently if authentication is not mandatory for the request url. This is spelled out in section 3.8. The module specific details are described in 3.8.3.1.
I will ask that the TCK add a test.

In the context of this issue in Servet, I would expect the same behavior to be required to handle "preemptive" authenticators, but as suggested by Mark, this could be limited to some specific auth mechanisms, in which case, it likely will be necessary to require the processing of an included authenticator.

Comment by markt_asf [ 12/Feb/13 09:10 AM ]

One additional point of clarification. If the user pre-emtively sends a user name and password that are not valid (user doesn't exist, wrong password, etc.) to an unprotected resource how should the container react? Should it reject the request because the credentials are invalid or should it allow the request and just ignore the credentials. I lean towards the former as I am concerned that the latter approach may open the door to brute force password cracking attempts.





[SERVLET_SPEC-22] Allow static resources to be served from WEB-INF/classes/META-INF/resources Created: 07/Oct/11  Updated: 07/Feb/13

Status: Open
Project: servlet-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Major
Reporter: markt_asf Assignee: Rajiv Mordani
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: markt_asf and Rajiv Mordani

 Description   

IDEs often unpack JAR files into the classes directory. This breaks the static resources from JAR files feature of Servlet 3.0. Allowing static resources to be read from the classes dir would address this.



 Comments   
Comment by Rajiv Mordani [ 07/Feb/13 01:19 AM ]

Would the order then be to first look for resources in WEB-INF/classes/META-INF/resources and then in the jar files?

Comment by markt_asf [ 07/Feb/13 08:20 AM ]

I think that makes sense as it would be consistent with the ordering for class-loading.

I don't have particularly strong feelings about what the order is but I do think that it is important that - if this feature is added - the specification clearly defines what the order is.





[SERVLET_SPEC-24] Clean-up of JNDI resources on application stop Created: 07/Oct/11  Updated: 22/Feb/13

Status: Open
Project: servlet-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Major
Reporter: markt_asf Assignee: Shing Wai Chan
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: FUTURE_RELEASE
Participants: arjan tijms, markt_asf, rojkov and Shing Wai Chan

 Description   

To facilitate a graceful shutdown of resources that does not rely on GC (which may not happen for some time) it would be helpful if there was a way to signal to JNDI resources that they were no longer required.

The suggestion is that on application stop, the resource is checked for a zero argument close() method and that this method is called if it is present.



 Comments   
Comment by arjan tijms [ 01/Dec/11 11:32 PM ]

>the resource is checked for a zero argument close() method and that this method is called if it is present.

What about checking for the java.lang.AutoCloseable interface instead?

Comment by markt_asf [ 02/Dec/11 09:33 AM ]

That would work if the minimum Java version is Java 7. The proposal was written based on a current Tomcat feature that runs on earlier Java versions.

The disadvantage of using java.lang.AutoCloseable is that it requires that the resource being closed is written for Java 7. That is not always the case. A fall-back for non-Java 7 resources would be nice.

Comment by arjan tijms [ 03/Dec/11 05:03 PM ]

>That would work if the minimum Java version is Java 7

Indeed, but a newer version of the Servlet spec could at least support newer Java versions, couldn't it?

>A fall-back for non-Java 7 resources would be nice.

Sure, although I would be wary of just calling unknown methods that happen to match a given signature. With the java.lang.AutoCloseable we can be sure the resource creator has written the resource being aware that the close() method will be automatically called.

At the very least I think there should be an option to disable the fall-back. It would be strange if a close method didn't just did what it said, but you never known. It's perhaps a bit far-fetched, but what if the JNDI resource represents some administrative system and close() means a domain specific action is carried out, like closing a 'payment period'?

Comment by rojkov [ 07/Dec/11 03:22 AM ]

I am obviously missing something, but how do we know a given resource belongs to the app in question and the app should be closing it.

Comment by markt_asf [ 07/Dec/11 06:03 PM ]

Definition of JNDI resources is container specific but the container will know if the resource is specific to an application or shared and can call / not call the close method accordingly.

Comment by rojkov [ 07/Dec/11 06:18 PM ]

If /foo binds a resource to JNDI for use by /bar, should shutting down /foo close the resource?

I think assumption that a container close any resource with a close() method may go too far, so there should at least be a way to exclude and include resources. And that needs to be weighted against advising programmers to use application specific ContextListener to clean up JNDI tree on shutdown.

Comment by Shing Wai Chan [ 22/Feb/13 10:29 PM ]

Adding it to the bucket of FUTURE_RELEASE





[SERVLET_SPEC-25] Require that filters that modify the response body must address content length and range requests Created: 07/Oct/11  Updated: 05/Mar/13

Status: Open
Project: servlet-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: markt_asf Assignee: Rajiv Mordani
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: markt_asf and Rajiv Mordani

 Description   

If a filter modifies the response body it may cause problems for a servlet if the servlets set a content length or respond correctly to range requests.

The specification currently implies that wrapping the response is necessary if the response body is modified. This issue requests that filters that modify the response body are required to correctly handle (which will almost certainly mean wrapping the response) range requests and the content-length of the response.



 Comments   
Comment by Rajiv Mordani [ 08/Feb/13 12:53 AM ]

Isn't it the job of the filter? Do you want the specification to state that the Response MUST be wrapped if the response is modified?

Comment by markt_asf [ 08/Feb/13 11:51 AM ]

This came out of a Filter in one of the TCK tests modifying a resource returned by Tomcat's default servlet and the test failing because the Filter lengthened the request body but left the content length header unchanged. My aim with this request was to push responsibility for failures in this case onto the Filter.

I've done some further thinking on this. Since not all Servlets will return a range for a range request or set an explicit content length it seems unreasonable to expect all Filters that modify response bodies to ensure range requests and content length issues are correctly handled. I don't think we should place an unnecessary burden on Filter developers. On that other hand, I'd like the specification to be clearer about the consequences of a Filter modifying a response body and where the responsibility lies if it breaks. How about along the lines of the following - probably at the end of section 6.1:

"Filters that modify the response body generated by a Servlet SHOULD not break the functionality of that Servlet. For example, if the Servlet supports range requests or sets an explicit content-length, the Filter SHOULD take steps to ensure that the response to the client is correct."

Part of me would like to replace the "SHOULD"s with "MUST"s but I think that would be too prescriptive.

Comment by Rajiv Mordani [ 05/Mar/13 01:29 AM ]

The problem with this is that even though the target Servlet may support range, content-length etc, how does the filter find out? Also a subsequent Filter in the filter chain may dispatch the request to some other servlet altogether. I am ok with the line you suggest above, but that does not guarantee that all containers will implement it that way.





[SERVLET_SPEC-26] Valid response header names and values Created: 07/Oct/11  Updated: 22/Feb/13

Status: Open
Project: servlet-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Major
Reporter: markt_asf Assignee: Shing Wai Chan
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: FUTURE_RELEASE
Participants: markt_asf and Shing Wai Chan

 Description   

Currently no validation is required when setting a response HTTP header or value. Should the specification require that invalid values are rejected? Should the specification provide a mechanism for escaping header names and values? What about values that cannot be escaped such as UTF-8 values?



 Comments   
Comment by Shing Wai Chan [ 22/Feb/13 10:29 PM ]

Adding it to the bucket of FUTURE_RELEASE





[SERVLET_SPEC-31] Async Request parameters Created: 27/Feb/12  Updated: 19/Jul/12

Status: Open
Project: servlet-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: gregwilkins Assignee: Rajiv Mordani
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: gregwilkins, Rajiv Mordani and rstoyanchev

 Description   

Section 9.7.2 describes a set of request attributes that contain the path values of the original request, so that they may be accessed by a servlet called as a result of a AsyncContext.dispatch(...)

However, this implies that these attributes are only set after a AsyncContext.dispatch(...), which means that they are not available to a thread that might be acting as part of a startAsync().... AsyncContext.complete() pattern.

Note that a thread cannot access the original request paths via AsyncContext.getRequest().getServletPath() because the value returned from that can be affected by forwards that happen before and/or after the startAsync call, or even a forward after an async dispatch. The path methods are inherently volatile.

I think that the ASYNC request parameters should be set when startAsync is called, so that those values are available for the entire async life cycle and not only during async dispatch.



 Comments   
Comment by gregwilkins [ 27/Feb/12 01:16 AM ]

Note also that the language used in this section could be improved, where it says:

The values of these attributes must be equal to the return values of the
HttpServletRequest methods getRequestURI, getContextPath, getServletPath,
getPathInfo, getQueryString respectively, invoked on the request object passed to
the first servlet object in the call chain that received the request from the client.

A request might never be passed to a servlet as it might be handled entirely by filters, or the first servlet object might be changed by a filter doing a dispatch.

Comment by rstoyanchev [ 19/Jul/12 01:34 PM ]

can be affected by forwards that happen before and/or after the startAsync call

Greg, the impression I got from SERVLET_SPEC-41 is that forwards cannot happen after a call to startAsync or are you referring to a different scenario?





[SERVLET_SPEC-37] Update Cookie class and other specifications for RFC 6265 Created: 29/Mar/12  Updated: 22/Feb/13

Status: Open
Project: servlet-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: gregwilkins Assignee: Shing Wai Chan
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: FUTURE_RELEASE
Participants: gregwilkins, markt_asf and Shing Wai Chan

 Description   

Currently the Cookie class defaults to supporting RFC 2019 cookies.
RFC2019 was obsoleted by RFC2965 in 2000, which in turn was obsoleted by RFC6265 in 2011

The latest RFC appears to be well supported by browsers (eg Google cookies often contain commas which are not allowed by 2019, but are by 6265).



 Comments   
Comment by gregwilkins [ 29/Mar/12 04:03 AM ]

Actually my example of a , in the cookie value is wrong, as although google appears do be doing that, it is not allowed by RFC6265.
However, I do believe it is worthwhile reviewing the Cookie class and other cookie related parts of the spec against the latest RFC.

Comment by markt_asf [ 29/Mar/12 09:00 AM ]

My experience has been that no matter what cookie specification is followed by the container, there will be a client or application that can't handle specification compliant values. We have had to add no end of hacks to Tomcat's cookie handling to allow checks to be bypassed to enable stuff to actually work. For example, anything that requires quoting (such as using commas in values) is often not handled correctly if it is quoted.

There is a clear unwillingness on the part of some browser vendors to adhere to the cookie specifications and no sign of this being a something that causes users to migrate to a more standards compliant browser.

I don't particularly like the situation that has lead to RFC 6265 (I would have preferred to see user demand driving browser compliance but that hasn't happened) but RFC 6265 is probably the best option since it is closer to what is actually happening than anything else. That said, I suspect container vendors will still need to add additional options to bypass some checks.

Comment by Shing Wai Chan [ 22/Feb/13 10:28 PM ]

Adding it to the bucket of FUTURE_RELEASE





[SERVLET_SPEC-39] Form Authentication redirection Created: 22/May/12  Updated: 22/Feb/13

Status: Open
Project: servlet-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: gregwilkins Assignee: Shing Wai Chan
Resolution: Unresolved Votes: 1
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: FUTURE_RELEASE
Participants: gregwilkins and Shing Wai Chan

 Description   

When a request is received that requires form authentication, the server remembers the original URL (and perhaps form encoded parameters) and redirects to a login page. Once the user completes the login form a request is sent to j_security_check, which if authentication is successful a redirection is sent to the saved URL.

However, since browsers have caches, iframes and javascript that issues ajax style requests, and since users can decline to authenticate on the first presentation of a web form, it is possible that for a given session multiple requests are received that are redirected to the login form. The problem for the server is to decide if it should eventually redirect to the first of the saved URLs; to the last of the saved; or to some heuristically chosen one in between.



 Comments   
Comment by gregwilkins [ 22/May/12 10:40 AM ]

A potential solution would be to allow a token to be passed from the initial redirect to the login form page, and for the login form page to be able to pass that token to the j_security_check request, so that the server can precisely determine the request that was redirected to the login form and thus redirect back to that request and not to some other stray request that came before or after.

If no token is present, then we should still firm up the definition of what saved URL j_security_check should redirect to.

Comment by Shing Wai Chan [ 22/Feb/13 10:27 PM ]

Adding it to the bucket of FUTURE_RELEASE





[SERVLET_SPEC-40] ServletInputStream.readLine has several problems Created: 30/May/12  Updated: 18/Jul/12

Status: Open
Project: servlet-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: gregwilkins Assignee: Rajiv Mordani
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

servlet 3.0


Tags:
Participants: gregwilkins and Rajiv Mordani

 Description   

The design and implementation of SerlvetInputStream.readLine has some design and implementation problems.

Firstly it is a strange method to have on a byte input stream, as a "line" may have no meaning or different meanings depending on content type. Many content types will not have the concept of a line, so this method will just strangely search for a \n byte. Other content types such as EBCDIC or UCS-2 may have different meanings of a \n byte, which still having the concept of a line.

Also, even with ASCII, UTF-8 text, lines may be terminated by \r, \r\n or just \n. Currently the implementation of this method will ignore \r and will return the \r in a \r\n sequence as part of the line.

The implementation is also not very efficient as it reads a single byte at a time.

Considering that this functionality is safely provided by BufferedReader, I believe that we should deprecate readLine - but also improve it's specification and implementation to:

+ throw illegalState exception if the content encoding is not a known to contain CR, LF characters
+ correctly handle CRLF, CR or LF






[SERVLET_SPEC-41] Clarify the limitations on using the request and response from an application thread Created: 04/Jun/12  Updated: 19/Jul/12

Status: Open
Project: servlet-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: rstoyanchev Assignee: Rajiv Mordani
Resolution: Unresolved Votes: 1
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: gregwilkins, Rajiv Mordani and rstoyanchev

 Description   

Section 2.3.3.4 of the Servlet 3.0 spec gives this advice on thread safety with regards to using the request and response objects in an async scenario:

"... they should either only be used within the scope of the request handling thread or the application must ensure that access to the request and response objects are thread safe."

This makes it clear they're not thread safe but also gives the impression that as long as access to these objects is synchronized, they can be used. However, in this servlet-spec user discussion, Greg Wilkins suggests there are a number of request methods that should probably never be used from an async thread including the context path, servlet path, path info, request URI, getting a RequestDispatcher, accessing the session (and possibly others) since their values may change.

Not surprisingly the behavior of Servlet containers varies. The scenario mentioned by Greg actually works in Tomcat and Glassfish potentially leading one to believe it's portable code. Even if one didn't intend on switching containers or didn't care about writing portable code, it's still not clear if the request and response can be used reliably or if they just happen to work in some scenarios.

The spec should make it clear what parts of the request and response should not be used from an application thread in an async scenario.



 Comments   
Comment by gregwilkins [ 06/Jun/12 01:20 PM ]

Note that just because tomcat and glassfish return non null values from these methods does not mean that they are "working".

In an environment where a request can be dispatched to one context, suspended by another context and then handled by yet another context, it is entirely undefined what values should be returned to an asynchronous thread calling any method dependant on the current context.

Jetty does return values to these methods depending on what context they are currently dispatched to, so if an async thread calls these methods before the original dispatch has returned, they will give non null value. If the request is not currently dispatched to a context, then these methods return their initial settings (contextPath==null, servletPath==null, pathInfo==requestedURI).

I think that only the request attributes should be asynchronously accessible (and my preference is to have an accessor method for these on AsyncContext).

Comment by rstoyanchev [ 19/Jul/12 01:29 PM ]

Greg, I am certainly not in a position to say if the values returned from the request in Glassfish and Tomcat after a call to startAsync work in general. On the contrary, I stated it's not clear if the request can be used reliably in that scenario and asked for clarification.

From the point of view of a Servlet API user, there is an AsyncContext and it provides access to the request and response. With no further indication in the spec and the Javadoc, it's not obvious that as many attributes and operations are to be avoided altogether.

I think that only the request attributes should be asynchronously accessible (and my preference is to have an accessor method for these on AsyncContext).

Do I understand correctly all other parts of the request should not be accessible?





[SERVLET_SPEC-44] Client close notification Created: 21/Aug/12  Updated: 10/Dec/13

Status: Reopened
Project: servlet-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: jitu Assignee: Shing Wai Chan
Resolution: Unresolved Votes: 13
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: jfarcand, jitu, Marek Potociar, Mikhail Mazursky, rstoyanchev and Shing Wai Chan

 Description   

There is no notification event for client close.
Is it possible to add AsyncListener#onClose() when the client is disconnected ? This will be
useful for long running connections like server-sent events connection.

On the other hand, SE socket API itself doesn't provide that option. So there may be no way to get client close notification when there is no pending i/o.



 Comments   
Comment by Marek Potociar [ 23/Aug/12 03:08 PM ]

onDisconnect(...) would be a better name IMO. Also, if that's not possible due to the lack of JavaSE Socket API, should it be clarified that onError(...) could be used for that purpose?

Comment by Shing Wai Chan [ 08/Jan/13 10:31 PM ]

There is no way to know when the socket is closed from SE API.

Comment by jfarcand [ 24/Apr/13 12:06 AM ]

I disagree. Any NIO layer can detect when the underlying connection is getting closed. Look at Grizzly/Tomcat NIO/Netty, they all able to handle that case.

Comment by Shing Wai Chan [ 24/Apr/13 01:25 AM ]

java.nio.channels.Channel#isOpen tests whether or not the channel is open.
So, we will revisit the issue.

Comment by Mikhail Mazursky [ 19/Jul/13 07:50 AM ]

Because this feature is missing it is not possible to stop resource consuming computations on server if client disconnects. Please, see this ticket for example https://sourceforge.net/apps/trac/bigdata/ticket/694

Comment by rstoyanchev [ 10/Dec/13 01:34 PM ]

Adding a link to a discussion on Tomcat's user list.

Comment by rstoyanchev [ 10/Dec/13 01:51 PM ]

As one example of why this matters consider the SockJS protocol that provides HTTP fallback options for WebSocket.

The protocol does not define any client-side "close" frame. It expects the server will detect when the HTTP connection is closed and indeed a variety of server-side implementations in a range of languages (node, erlang, python, ruby) do.

A Java implementation – with Servlet 3 async for the long polling or HTTP streaming – however cannot detect when a client has gone away. This is a very fundamental, missing feature that puts Java Servlet-based implementations at a significant disadvantage.





[SERVLET_SPEC-45] Access to connector/socket container info Created: 03/Sep/12  Updated: 01/Mar/13

Status: Open
Project: servlet-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: c.beikov Assignee: Rajiv Mordani
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: FUTURE_RELEASE
Participants: c.beikov, Rajiv Mordani and Shing Wai Chan

 Description   

As discussed in the mailing list[1] a suggestion on how to extend the current api to expose information about the underlying connectors/sockets.
This is just the first idea that came into my head. Please suggest better ideas if you can think of any. Since I was just targeting to expose something like the https port to the application, I did't thought of better changes.

public interface ServletContext { // existing members public Set<ServletConnector> getConnectors(); }

public interface ServletConnector{ public int getPort(); public String getProtocol(); public boolean isSecure(); }

[1] http://java.net/projects/servlet-spec/lists/users/archive/2012-08/message/7



 Comments   
Comment by Shing Wai Chan [ 22/Feb/13 09:15 PM ]

Adding it to the bucket of FUTURE_RELEASE





[SERVLET_SPEC-50] Configure <error-page> programmatically in Servlet 3.0 Created: 01/Nov/12  Updated: 01/Mar/13

Status: Open
Project: servlet-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: shijas Assignee: Shing Wai Chan
Resolution: Unresolved Votes: 3
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: FUTURE_RELEASE
Participants: arjan tijms, Rajiv Mordani, shijas and Shing Wai Chan

 Description   

Web.xml can be programmatically created using Servlet 3.0. But features like <error-page> , < session-timeout> still needs to be configured in a web.xml.Can you provide a way to programmatically create these as well? Especially, error-page configuration.



 Comments   
Comment by Rajiv Mordani [ 09/Jan/13 07:55 AM ]

While we did provide programmatic APIs for adding servlets, filters and listeners, we have not exposed a full API for processing every element in the descriptor via APIs. Note that the programmatic APIs are not a complete replacement for the descriptor. It still makes sense to specify certain aspects via descriptors - just like in the case of annotations.

Comment by arjan tijms [ 09/Feb/13 09:15 PM ]

Ideally, every element (with some exceptions) would be settable in 3 ways, namely via:

  • The traditional descriptor
  • An annotation
  • A high level programmatic API

Note that JSF 2.2 introduced a method that's between the descriptor and the programmatic API: a call-back in which the descriptor is exposed as a DOM tree and can be programmatically manipulated. See http://jdevelopment.nl/jsf-22/#533 You could call this a low level programmatic API.

It might make sense to adopt the JSF 2.2 method for web.xml.





[SERVLET_SPEC-52] Clarify behaviour when the same filter is matched by several filter-mapping elements Created: 07/Jan/13  Updated: 09/Jan/13

Status: Open
Project: servlet-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: kkolinko Assignee: Shing Wai Chan
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: kkolinko and Shing Wai Chan

 Description   

The chapter 6.2.4 Configuration of Filters in a Web Application defines how a container builds the chain of filters to be applied to a particular request URI.

My question is what should happen if there are several matching filter-mappings for the same filter (either by different <url-pattern>s, or by an <url-pattern> and a <servlet-name>):
whether
a) the filter has to be called several times, as many as how many matching <filter-mapping>s are there.
or
b) the filter has to be called only once, honoring the first filter-mapping that matches,

An example:

<filter-mapping>
<filter-name>filterA</filter-name>
<url-pattern>/view/*</url-pattern>
<url-pattern>*.do</url-pattern>
</filter-mapping>

If the requested URI is "/view/bar.do", does the filter have to be called twice?

My own reading is that "a)" (multiple calls) is what is implied by that chapter, but I would like this to be mentioned explicitly.

If actually the requirement is "b)" (single call), then I would like someone to clarify what mapping takes priority when there is both an url-pattern and a servlet-name match. As the servlet-name mappings are processed first, it seems that the servlet-name mapping wins, but it is confusing as those filters are positioned later in the resulting filter chain than the ones mapped by url-patterns.

In Tomcat 7 the "b)" behaviour was implemented but with url-patterns having the priority, stemming from the following issue:
https://issues.apache.org/bugzilla/show_bug.cgi?id=49922






[SERVLET_SPEC-58] Support getting parameters from PUT requests Created: 19/Feb/13  Updated: 01/Mar/13

Status: Open
Project: servlet-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: sslavic Assignee: Rajiv Mordani
Resolution: Unresolved Votes: 7
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: FUTURE_RELEASE
Participants: Rajiv Mordani, Shing Wai Chan and sslavic

 Description   

Many web frameworks, and some servlet containers have custom solutions which allow accessing request parameters from PUT requests. See related servlet-spec users mailing list discussion for more details.
It would benefit all if this support was covered in servlet spec.

Latest, Servlet 3.1 public review spec, has related paragraph:

3.1.1 When Parameters Are Available
The following are the conditions that must be met before post form data will be
populated to the parameter set:
1. The request is an HTTP or HTTPS request.
2. The HTTP method is POST.
3. The content type is application/x-www-form-urlencoded.
4. The servlet has made an initial call of any of the getParameter family of methods
on the request object.
If the conditions are not met and the post form data is not included in the parameter
set, the post data must still be available to the servlet via the request object's input
stream. If the conditions are met, post form data will no longer be available for
reading directly from the request object's input stream.

If there is no valid reason not to support PUT requests this paragraph should be changed to something like:

3.1.1 When Parameters Are Available
The following are the conditions that must be met before form data will be
populated to the parameter set:
1. The request is an HTTP or HTTPS request.
2. The HTTP method is POST or PUT.
3. The content type is application/x-www-form-urlencoded.
4. The servlet has made an initial call of any of the getParameter family of methods
on the request object.
If the conditions are not met and the form data is not included in the parameter
set, the data must still be available to the servlet via the request object's input
stream. If the conditions are met, form data will no longer be available for
reading directly from the request object's input stream.



 Comments   
Comment by Shing Wai Chan [ 22/Feb/13 09:14 PM ]

Adding it to the bucket of FUTURE_RELEASE





[SERVLET_SPEC-59] Add 'query_string' request attribute to the Error dispatched requests Created: 20/Feb/13  Updated: 01/Mar/13

Status: Open
Project: servlet-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: martin_grigorov Assignee: Shing Wai Chan
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: FUTURE_RELEASE
Participants: martin_grigorov and Shing Wai Chan

 Description   

The servlet specification defines javax.servlet.forward.query_string and javax.servlet.include.query_string, but no javax.servlet.error.query_string.
If there is not specific reason why this attribute is excluded from the specification please add it for the next release.



 Comments   
Comment by Shing Wai Chan [ 22/Feb/13 09:18 PM ]

Adding it to the bucket of FUTURE_RELEASE





[SERVLET_SPEC-60] Provide HttpServletRequestWrapper that minimizes effort required to override core data Created: 20/Feb/13  Updated: 01/Mar/13

Status: Open
Project: servlet-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Major
Reporter: arjan tijms Assignee: Rajiv Mordani
Resolution: Unresolved Votes: 1
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: arjan tijms and Rajiv Mordani

 Description   

While the Servlet spec provides an HttpServletRequestWrapper that makes it easy to wrap an existing HttpServletRequest and override a specific method, there's still a significant amount of work needed to fully override all methods that are related to a singe "data item".

For instance, if it's needed to provide different headers for a wrapped request, it's not possible to simply override a single method that provides a collection of headers. Instead no less than 5 methods need to be overridden:

  • getHeaderNames
  • getHeader
  • getHeaders
  • getIntHeader
  • getDateHeader

Specifically, in the above example it's not exactly trivial to implement getDateHeader. It should theoretically not be needed to provide a custom implementation of this getDateHeader method since the Servlet implementation already has one, but there's no portable way to use that.

If it's needed to provide another URL even more methods have to be overridden (getContextPath, getPathInfo, etc).

It would be great if a wrapper class could be provided that identified a number of "core data" items, such as cookies, headers, locales, parameters, the request method, URL and query String, where for each of which the user could provide that "core data" item by overriding a single method.

All methods that provide derived data would call this single method in their container provided implementations. (this is loosely based on the concept of AbstractMap in Java SE, where a user only has to implement a minimal amount of functionality in order to have reasonable implementations for all methods of the complex Map interface)






[SERVLET_SPEC-61] Provide an isAccessAllowed method to see if user has access to URL Created: 20/Feb/13  Updated: 13/Feb/14

Status: Open
Project: servlet-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Major
Reporter: arjan tijms Assignee: Shing Wai Chan
Resolution: Unresolved Votes: 3
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: FUTURE_RELEASE
Participants: arjan tijms, balusc, Darious3, kithouna and Shing Wai Chan

 Description   

Following the Servlet spec, security constraints can be specified in web.xml. The Servlet container internally uses these to determine whether the current user has access to a given URL (Servlet 3.0 specification Section 12.1).

There is however no method in the public API that user code can use to do the same check. A use case for this would be the rendering of a list of links (e.g. in a menu), where the requirement is to not render those links where the user does not have access to. Without a means to ask the Servlet container about the access for every link, the code must either duplicate the URL-role association somewhere (perhaps in a custom XML file), or has to duplicate the algorithm from Section 12.1.

Both solutions are not ideal, since the container already maintains this association and already has an implementation of said algorithm.

Therefor I would like to request a "boolean isAccessAllowed(String url, String role)" method to be provided by the Servlet API, perhaps added to HttpServletRequest, that user code can use to determine if the current user has access to a given URL (relative to the context root of the web app).



 Comments   
Comment by balusc [ 20/Feb/13 08:30 PM ]

Putting it on ServletContext makes more sense. Having it on HttpServletRequest would be only useful if you'd like to check it against the currently logged-in user as in boolean isAccessAllowed(String url).

Comment by arjan tijms [ 20/Feb/13 09:57 PM ]

@balusc, you're right. Unfortunately I can't edit the description anymore.

Having two versions of the requested method would be ideal; one to do the check for the current user, and one to do the check for a given role independent of who the current user is.

Comment by Shing Wai Chan [ 22/Feb/13 10:22 PM ]

This can be achieved by checking javax.security.jacc.WebResourcePermission in JACC.

I am not sure whether it is necessary to provide the same functionality in Servlet spec.
Adding it to the bucket of FUTURE_RELEASE.

Comment by Darious3 [ 09/Jun/13 11:14 AM ]

Shing, does this mean that JACC will be a mandatory part of Servlet in the future?

At the moment JACC is not available in the Java EE Web Profile, and certainly not in Servlet Containers. JACC is also a bit difficult and arcane to work with. Even in the Java EE Full Profile an easier method to do this check would be a plus.

Comment by arjan tijms [ 05/Feb/14 10:26 PM ]

This can be achieved by checking javax.security.jacc.WebResourcePermission in JACC.

The problem is that even in containers that should support JACC (i.e. full Java EE implementations) JACC just isn't always there, but has to be "enabled". See e.g. the weblogic instructions:

To enable the WebLogic JACC Provider from the command line, you must specify the following system property/value pairs:

Property: java.security.manager

Value: No value required.

Property: java.security.policy

Value: A valid weblogic.policy file, specified using either a relative or an absolute pathname

Property: javax.security.jacc.PolicyConfigurationFactory.provider

Value: weblogic.security.jacc.simpleprovider.PolicyConfigurationFactoryImpl

Property: javax.security.jacc.policy.provider

Value: weblogic.security.jacc.simpleprovider.SimpleJACCPolicy

Property: weblogic.security.jacc.RoleMapperFactory.provider

Value: weblogic.security.jacc.simpleprovider.RoleMapperFactoryImpl

Source: http://docs.oracle.com/cd/E24329_01/web.1211/e24485/server_prot.htm#i1037363

I think it would not be unreasonable to assume that very few if any developers let alone anyone from IT will do this just to enable what should be a relatively simple utility method.

I also wonder how exactly you would code both versions of the required functionality with JACC. I can think of code such as the following;

Subject subject = (Subject) PolicyContext.getContext("javax.security.auth.Subject.container");
              
          boolean test = Policy.getPolicy().implies( new ProtectionDomain(
                new CodeSource(null, (Certificate[]) null),
                null, null, 
                subject.getPrincipals().toArray(new Principal[subject.getPrincipals().size()])
                ), 
                new WebResourcePermission("/protected/Servlet", ""))
            ;

But this will test if the current authenticated user has access, not if a given role has access. We can't just pass in a Principal for just the role we're looking for since the representation of that is container specific, isn't it?

Comment by kithouna [ 13/Feb/14 01:20 PM ]

The problem is that even in containers that should support JACC (i.e. full Java EE implementations) JACC just isn't always there, but has to be "enabled".

It's even worse...

Some containers don't even ship with a default JACC provider! WebSphere only ships with a JACC provider that is a client for an external Tivolo Access Manager server. There is no such thing as a default internal JACC provider. See http://pic.dhe.ibm.com/infocenter/wasinfo/v8r5/index.jsp?topic=%2Fcom.ibm.websphere.nd.multiplatform.doc%2Fae%2Fcsec_jaccintegrate.html

In other words, the JACC methods for getting the current Subject and asking for roles etc are just not available on WebSphere. Since WebSphere is fully Java EE certified and TCK tested we can only conclude that JACC isn't really part of Java EE. I mean, the SPI to interface with a JACC provider is, but the actual JACC functionality isn't.





[SERVLET_SPEC-62] Provide a getAllUserRoles method Created: 20/Feb/13  Updated: 13/Feb/14

Status: Open
Project: servlet-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Major
Reporter: arjan tijms Assignee: Shing Wai Chan
Resolution: Unresolved Votes: 2
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: FUTURE_RELEASE
Participants: arjan tijms, kithouna and Shing Wai Chan

 Description   

The Servlet API offers a method to retrieve the current user's principal (HttpServletRequest#getUserPrincipal) and a method that can be used to determine if the current user has a specific role (HttpServletRequest#isUserInRole).

There is however no corresponding method or way to retrieve a list with all roles that the current user has in a portable way. There is potentially a way to do this via JACC, but that's not exactly a straightforward way, plus JACC is not universally available in Servlet containers. A use case for this is e.g. displaying to the user a list of all roles he or she has, or the ability to input such a list of roles into a custom authorization system.

I would be great if such a method could be added.



 Comments   
Comment by Shing Wai Chan [ 22/Feb/13 09:42 PM ]

JACC provide a way to plugin a custom authorization system.
There are corresponding API to add role in javax.security.jacc.PolicyConfiguration.

I am not sure whether it is necessary to add those API in Servlet as we already have a mechanism to do that in JACC.

Adding it to the bucket of FUTURE_RELEASE.

Comment by arjan tijms [ 22/Feb/13 10:42 PM ]

I am not sure whether it is necessary to add those API in Servlet as we already have a mechanism to do that in JACC.

I indeed mentioned JACC as a potential way, but it's not exactly trivial. See this post (it's one of the few sources on this topic): https://blogs.oracle.com/monzillo/entry/using_jacc_to_determine_a and an associated forum thread: http://glassfish.10926.n7.nabble.com/Fetch-all-roles-assigned-to-an-user-td30843.html

If you look at the code and some of the assumptions, then it can be seen that it's really not trivial. In practice I rarely see people using such code, and I'm not 100% convinced it really works everywhere.

Whether it should be in Servlet is perhaps another question. Maybe there should be an overarching modern and easy to use security system in Java EE so a similar method would not have to be duplicated for e.g. EJB. However, since such overarching security system is not there now and HttpServletRequest already has methods that come close, it seems like a natural addition.

Comment by kithouna [ 13/Feb/14 01:25 PM ]

I am not sure whether it is necessary to add those API in Servlet as we already have a mechanism to do that in JACC.

But JACC tells us only how to interface with a custom authorization system. If we don't want that (majority of the cases) but just want to use the default authorization system, it's still reasonable to want to know the roles of the current user.

If JACC only required that each server had a default JACC implementation corresponding to the standard Servlet and EJB authorization rules, then yeah, JACC would work. But as it stands it doesn't.





[SERVLET_SPEC-63] Consider adding an option to set Strict-Transport-Security header in web.xml Created: 21/Feb/13  Updated: 01/Mar/13

Status: Open
Project: servlet-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: Samuel Santos Assignee: Shing Wai Chan
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: FUTURE_RELEASE security web-a
Participants: markt_asf, Samuel Santos and Shing Wai Chan

 Description   

Transparent redirection to HTTPS means that the vast majority of the time your users are on your site, they'll be using a secure connection. It does, however, leave a small window of opportunity for attack: the initial HTTP connection is wide open, vulnerable to SSL stripping and related attacks. Given that a man in the middle has complete access to the initial HTTP request, it can act as a proxy between you and the server, keeping you on an insecure HTTP connection regardless of the server's intentions.

You can mitigate the risk of this class of attack by asking the browser to enforce HTTP Strict Transport Security (HSTS). Sending the Strict-Transport-Security HTTP header instructs the browser to do the HTTP to HTTPS redirection client-side, without ever touching the network (this also happens to be great for performance; the best request is the one you don't have to make).

Please consider adding an option to set this header in web.xml.



 Comments   
Comment by markt_asf [ 21/Feb/13 01:07 PM ]

HSTS itself has a fairly large flaw in that the MITM can just remove the header before it ever reaches the client.

I'm not convinced of the usefulness of this mitigation. Sites that want to use it can always write a simple filter to add it.

Comment by Shing Wai Chan [ 22/Feb/13 10:23 PM ]

Adding it to the bucket of FUTURE_RELEASE





[SERVLET_SPEC-65] Add CORS (Cross-Origin Resource Sharing) support in web.xml Created: 05/Mar/13  Updated: 05/Mar/13

Status: Open
Project: servlet-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: Samuel Santos Assignee: Shing Wai Chan
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: FUTURE_RELEASE cors security servlet
Participants: Samuel Santos and Shing Wai Chan

 Description   

http://www.w3.org/TR/cors/ describes a mechanism to allow secure cross-origin resource sharing.
Please consider adding support for it in web.xml.






[SERVLET_SPEC-66] Need way to track progress of requests; proposal included Created: 10/Mar/13  Updated: 24/Apr/13

Status: Open
Project: servlet-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: Nick Williams Assignee: Shing Wai Chan
Resolution: Unresolved Votes: 1
Remaining Estimate: 2 hours
Time Spent: Not Specified
Original Estimate: 2 hours
Environment:

n/a


Tags: multipart upload progressbar
Participants: Eugene Chung, Nick Williams and Shing Wai Chan

 Description   

Servlet 3.0 added multipart request processing to, in part, make handling file uploads easier (and easier it did make it). Before 3.0, many users used Commons FileUpload to accomplish this task. However, 3.0's multipart processing did not, unfortunately, completely eliminate the need for FileUpload. One of the major features lacking is the ability to track the progress of a large request.

This feature is sometimes called "file upload progress," but that name is misleading. It's actually "request progress," and it's the ability to measure and periodically report the number of bytes actually received versus the number of bytes indicated in the "Content-Length" header. As I propose below, I believe this should be relatively easy to add to the servlet spec, relatively easy to implement, and quite easy to use.

As proposed, this is independent of protocol (not strictly tied to HTTP/multipart/Content-Length). That could be changed, but I think this makes sense.

First, create a new interface:

ServletRequestProgressListener
package javax.servlet;

public interface ServletRequestProgressListener
{
    /**
     * Called whenever the number of bytes read changes, at least every 64 kilobytes.
     *
     * @param bytesRead The number of bytes that have been read so far, at least 0
     * @param bytesExpected The number of bytes expected to be read, -1 if unknown
     * @param itemsRead The number of items (parts in an HTTP multipart) processed so far
     */
    void update(long bytesRead, long bytesExpected, int itemsRead);

    /**
     * Called whenever the request has ended, either by being canceled or completed, 
     * normally or abnormally.
     */
    void destroy();
}

Next, add a method to ServletRequest:

ServletRequest
...
    /**
     * Attaches a progress listener to this request. Progress listeners must be attached in
     * a filter, before the request gets to the Servlet, in order to be effective.
     * 
     * @param progressListener The progress listener to update when the bytes read increases
     * @throws UnsupportedOperationException if the protocol does not support progress listeners
     */
    void setProgressListener(ServletRequestProgressListener progressListener);
...

Because the listener can be a source of performance problems, containers would only be required to call update (1) when first attached, and (2) every 64 kilobytes. Containers may call it more often, but do not have to. As proposed, I estimate 30 minutes to create the proposed interfaces and 1.5 hours to update the servlet specification documentation. Should only take 2-3 hours to add to the Tomcat implementation based on my examination of the code. Can't speak for the other implementations.

Using multipart as the primary example, since multipart processing is completed before the Servlet gets the request, the listener would have to be attached in a filter. A typical use case would be to create a listener and add it to a session so that it can later be queried by some Ajax call:

Psuedo-Code
...
    public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain)
    {
        if(request-is-large)
        {
            MyProgressListener listener = new MyProgressListener(request);
            request.getSession().addAttribute("progressListener", listener);
            request.setProgressListener(listener);
        }
    }
...


 Comments   
Comment by Nick Williams [ 10/Mar/13 11:47 PM ]

One unfortunate problem with NOT adopting this suggestion (in some form or another) is that here is no work-around that works within the spec. Either you don't have progress bars, or you don't use the multipart support added in 3.0. There's no "hard way" in the spec that this makes easier. This is making something possible that is currently impossible within the spec.

Comment by Eugene Chung [ 11/Mar/13 12:50 AM ]

+1

But all listeners of servlet are added via configuration(at deploy time). I think your suggestion, which is adding a listener at service time, can break consistency.

Comment by Nick Williams [ 11/Mar/13 01:15 AM ]

I thought about that, and my original draft had this set up as a configuration item, but there's a problem with that. All of the other listeners are configured across the servlet context. A session listener listens for new sessions or changes to sessions; a request listener gets notified of request events; a servlet context listener observes when the context starts and stops.

But this listener is very different. In fact, it is nothing like the other listeners at all. One of these listeners would be created for exactly one request. When that request was over, the listener would be destroyed and would no longer have any purpose. The update method makes it apparent why this is the case.

Perhaps, to make it clear that this is not a listener in the Servlet sense, it should have a different name, such as ServletRequestProgressFollower and setProgressFollower, but "listener," in a generic sense, really does describe what it's for.

(Also: should there be a getProgressListener/getProgressFollower method on ServletRequest in addition to the mutator?)

Comment by Nick Williams [ 11/Mar/13 01:45 AM ]

Actually, now that I think about it, maybe ServletRequestProgressFollower would be a better name...

Comment by Nick Williams [ 11/Mar/13 01:36 PM ]

I know this suggestion is pushing the line for Servlet 3.1, but I think it's a big improvement worth consideration. If there's anything I can do to help, I'm willing to drop whatever I'm working on to make it happen. I'm hoping there's time for just one more thing for Servlet 3.1.

If it comes to choosing between this and issue #67, 67 can definitely wait until 3.next, because it has a workaround. This issue, unfortunately, does not have a workaround.

Comment by Nick Williams [ 01/Apr/13 04:05 PM ]

I'd love to get some feedback on this. I haven't seen any discussion about it on the EG mailing list. Does the proposal need changes? Is it too late to add? That would be unfortunate, since there is no workaround.





[SERVLET_SPEC-67] Add support for obtaining path parameter information from HttpServletRequest Created: 11/Mar/13  Updated: 25/Apr/13

Status: Open
Project: servlet-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: Nick Williams Assignee: Rajiv Mordani
Resolution: Unresolved Votes: 2
Remaining Estimate: 3 hours
Time Spent: Not Specified
Original Estimate: 3 hours
Environment:

n/a


Tags: pathsegment pathparameter matrixparameter request
Participants: Nick Williams, Rajiv Mordani and rstoyanchev

 Description   

URI paths can contain parameters, independent of the query string. Parameters belong to the path segment within which they appear and to the URI as a whole. Parameters are separated from the segment and from each other with a semicolon (;), and parameter values are separated from each other with a comma (,). For example, consider the following URL:

http://www.example.org/foo;x=1;y=2/bar;a=3,4;y=5

In this example, x is 1 and y is 2 or the /foo segment, while a is [3, 4] and y is 5 for the /bar segment. For the entire URL, a appears once and has 2 values, x appears once and has 1 value, and y appears twice and has 1 value and 1 value.

The servlet spec already recognizes path parameters, though it does not actually provide an interface for extracting them. As an example of this, if application /foo is deployed at example.org and it has a Servlet mapped to /bar, the aforementioned URL will match that context and servlet. A call to HttpServletRequest#getContextPath() will return /foo, not /foo;x=1;y=2, and a call to HttpServletRequest#getServletPath() will return /bar, not /bar;a=3,4;y=5.

This suggestion is to add two methods to HttpServletRequest:

...
    /**
     * Returns all of the path (matrix) parameters that appear in the request URI. The keys in the
     * map are the parameter names. The map values are lists of entries. If a parameter appears
     * in one path segment, there will be one value in the list, and that value may be one or more
     * strings. If a parameter appears in multiple path segments, there will be a value in the list
     * for each path segment, in the order the path segments appear in the URI. Each value may
     * be one or more strings.
     * <p>
     * Path parameters are separated from their segments and the ... [explanation from above]
     *
     * @return the parameters present in all path segments in the URI.
     */
    Map<String, List<String[]>> getPathParameters(); // could be Map<String, List<List<String>>> instead
...
    /**
     * Returns a list of all path segments in the request URI. Path segments are separated by the
     * forward slash (/). The path segments returned by this method will include the context
     * path and the Servlet path.
     *
     * @return a list of all the path segments in the request URI, in the order they appear.
     */
    List<PathSegment> getPathSegments();
...

A call to either getPathParameters or getPathSegments results in the processing and caching of all path parameters. This is independent of the processing and caching of request parameters (getParameter, getParameterNames, etc.). The processing of path parameters should not trigger the processing of request parameters, and vice versa. If easier/more efficient, the container may process path parameters when it decodes the URI (note that parameter processing should be performed against the URI before decoding, but parameter names and values should be decoded).

(Importantly, if I call getPathParameters or getPathSegments within a filter, it should not block while POST parameters or multipart data (unrelated) are processed.)

The new javax.servlet.http.PathSegment interface is modeled off of the javax.ws.rs.core.PathSegment interface, which exists for the same purpose:

package javax.servlet.http;

public interface PathSegment
{
    /**
     * Returns the path for this specific segment, including the leading forward slash (/).
     *
     * @return the path for this segment.
     */
    String getPath();

    /**
     * Returns the path (matrix) parameters that appear in this segment. The keys in
     * the map are the parameter names. The values are all of the values assigned to
     * the corresponding parameters. A parameter may have one or more values.
     * <p>
     * Path parameters are separated from their segments and the ... [explanation from above]
     */
    Map<String, String[]> getParameters(); // could be Map<String, List<String>> instead
}

There is currently a workaround to accomplishing this, though it has its disadvantages. Parameters could simply be processed as-needed by the application using its own or third-party code. Or a filter could be written to process parameters and add them to the request as a request attribute. The key problem with both of these approaches is that the container knows what character encoding was used for the URI, but the application does not. It would be more accurate and reliable for the container to perform the parameter processing.

For the most information, I have included parts a sample filter below that I created for use in my application. Some of the code (namely the POJOs) is inferred.

...
    @Override
    public void doFilter(ServletRequest request, ServletResponse response,
                         FilterChain chain) throws IOException, ServletException
    {
        String[] paths = ((HttpServletRequest)request).getRequestURI()
                .substring(1).split("/");
        PathInfo info = new PathInfo();

        for(String path : paths)
        {
            String[] parts = path.split(";");
            PathSegment segment = new PathSegment();
            segment.path = parts[0];
            for(int i = 1; i < parts.length; i++)
            {
                String[] p = parts[i].split("=", 2);
                String key = decode(p[0]);
                if(p.length == 2)
                    segment.parameters.put(key, decode(p[1].split(",", -1)));
                else
                    segment.parameters.put(key, new String[] {""});
                if(!info.parameters.containsKey(key))
                    info.parameters.put(key, new ArrayList<>());
                info.parameters.get(key).add(segment.parameters.get(key));
            }
            info.segments.add(segment);
        }

        request.setAttribute("com.wrox.pathInfo", info);

        chain.doFilter(request, response);
    }

    private String decode(String original)
    {
        try {
            return URLDecoder.decode(original, "UTF-8");
        } catch (UnsupportedEncodingException e) {
            throw new RuntimeException(e); // not possible
        }
    }

    private String[] decode(String[] original)
    {
        String[] newValues = new String[original.length];
        for(int i = 0; i < original.length; i++)
        {
            try {
                newValues[i] = URLDecoder.decode(original[i], "UTF-8");
            } catch (UnsupportedEncodingException e) {
                throw new RuntimeException(e); // not possible
            }
        }
        return newValues;
    }
...

Estimate 30 minutes to add the relevant methods/interfaces and 2.5 hours to update the spec doc.



 Comments   
Comment by Nick Williams [ 11/Mar/13 01:54 AM ]

Also, I believe the spec should specify the following important notes:

  • Containers should preserve empty parameter values. So, if a parameter exists where x=1,,2,3,,,4,, the resulting values should be ["1", "", "2", "3", "", "", "4", ""]. If x=, then the resulting values should be [""].
  • Users should be warned that browsers do not recognize or interpret path parameters, and as a result they can interfere with cookies. If a cookie is set to path /foo, requests to /foo/bar will include the cookie but requests to /foo;a=1/bar will not include the cookie. However, requests to /foo/bar;a=1 will include the cookie, since the path parameters are not interfering with the cookie path in this case.
Comment by Nick Williams [ 11/Mar/13 01:38 PM ]

If this can make it in Servlet 3.1, great. If not, no big deal. There is a workaround, so it is not crucial that this be in 3.1.

Comment by rstoyanchev [ 25/Apr/13 08:07 PM ]

While the above understanding of path parameters is correct, note that it represents one of several styles of path parameters. RFC 3986 (section 3.3) is relatively vague and leaves a lot of room:

For example, the semicolon (";") and equals ("=") reserved characters are
often used to delimit parameters and parameter values applicable to
that segment.  The comma (",") reserved character is often used for
similar purposes.  For example, one URI producer might use a segment
such as "name;v=1.1" to indicate a reference to version 1.1 of
"name", whereas another might use a segment such as "name,1.1" to
indicate the same.

This probably reflects the fact that a few different styles of path parameters have evolved over time in the absence of a very precise definition. In addition to the above examples, here is one other example from the StackExchange API where a path segment contains a ";" separated list of ids (the ";" in this case is merely a separator):

http://api.stackoverflow.com/1.1/usage/methods/comments-by-ids





[SERVLET_SPEC-68] Change HttpSessionListener to extend new HttpSessionCreateListener, HttpSessionDestroyListener Created: 18/Mar/13  Updated: 24/Apr/13

Status: Open
Project: servlet-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: Nick Williams Assignee: Rajiv Mordani
Resolution: Unresolved Votes: 0
Remaining Estimate: 2 hours
Time Spent: Not Specified
Original Estimate: 2 hours

Tags:
Participants: Nick Williams and Rajiv Mordani

 Description   

The HttpSessionListener interface contains two methods: sessionCreated() and sessionDestroyed(). Sometimes listeners are only interested in creation or destruction, but not both. Also, this prevents lambda expressions from being passed to ServletContext#addListener(T) for creation and destruction events. For example, I can add an HttpSessionIdListener listener to a ServletContext with a lambda expression:

context.addListener((HttpSessionIdListener)(e, s) -> {
    // do something
});

I'd like to also be able to do:

context.addListener((HttpSessionCreateListener)(e) -> {
    // do something
});
context.addListener((HttpSessionDestroyListener)(e) -> {
    // do something
});

Particularly, I might not care about creation events, so I might just do the latter.

I recommend:

interface HttpSessionCreateListener
    - sessionCreated(HttpSessionEvent)
interface HttpSessionDestroyListener
    - sessionDestroyed(HttpSessionEvent)
interface HttpSessionListener extends HttpSessionCreateListener, HttpSessionDestroyListener

This would be a compile-safe change and would not break web applications with existing HttpSessionListeners.

There are a few other interfaces that could possibly use a similar separation, though I am not suggesting that this be applied to ALL of them:

HttpSessionActivationListener:
    HttpSessionActivateListener
    HttpSessionPassivateListener
HttpSessionAttributeListener:
    HttpSessionAttributeAddListener
    HttpSessionAttributeRemoveListener
    HttpSessionAttributeReplaceListener
HttpSessionBindingListener:
    HttpSessionBindListener
    HttpSessionUnbindListener
ServletContextAttributeListener:
    ServletContextAttributeAddListener
    ServletContextAttributeRemoveListener
    ServletContextAttributeReplaceListener
ServletContextListener:
    ServletContextDestroyListener
    ServletContextInitializeListener
ServletRequestAttributeListener:
    ServletRequestAttributeAddListener
    ServletRequestAttributeRemoveListener
    ServletRequestAttributeReplaceListener
ServletRequestListener:
    ServletRequestDestroyListener
    ServletRequestInitializeListener





[SERVLET_SPEC-70] Programmatic configuration API missing setting to replace <session-timeout> Created: 23/Mar/13  Updated: 09/Aug/13

Status: Open
Project: servlet-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Nick Williams Assignee: Shing Wai Chan
Resolution: Unresolved Votes: 3
Remaining Estimate: 1 hour
Time Spent: Not Specified
Original Estimate: 1 hour

Tags: servlet-context sessions session-timeout
Participants: Eugen Paraschiv, kithouna, Nick Williams and Shing Wai Chan

 Description   

I just realized that there's no replacement for the deployment descriptor's <session-timeout> in ServletContext. Everything else in <session-config> (<tracking-mode> and all of the <cookie-config> options) can be set with ServletContext, but <session-timeout> cannot. I literally have a web.xml that is just the following:

<web-app ... version="3.0">
    <session-config>
        <session-timeout>30</session-timeout>
    </session-config>
</web-app>

Seems like kind of a big thing to be missing. Can we get setSessionTimeout and getSessionTimeout methods in ServletContext? It only makes sense, since ServletContext also has setSessionTrackingModes and getSessionTrackingModes methods.

I'd add that we really need a setDistributable and isDistributable, but I see those as lower priorities. Admittedly, there are plenty of things you can only do with web.xml, but session timeouts stick out because everything else from the <session-config> group can be configured programmatically.



 Comments   
Comment by Eugen Paraschiv [ 26/Jul/13 09:48 AM ]

This would definitely help get rig of the last remaining XML pieces.

Comment by kithouna [ 09/Aug/13 04:31 PM ]

We should definitely have this. I agree with OP that everything in web.xml should be possible to do programmatically, but of all those things this should really be done.





[SERVLET_SPEC-72] HttpUpgradeHandler and resource injection Created: 01/May/13  Updated: 27/Jun/13

Status: Open
Project: servlet-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: janbartel Assignee: Shing Wai Chan
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: janbartel, Shing Wai Chan and wizard.liyd

 Description   

Servlet Spec 3.1, section 15.5, table 15.1 does not list the new HttpUpgradeHandler interface as supporting resource injection, postconstruct/predestroy annotations.

However the JavaEE 7 spec, section 5.2.5 table 5.1 does list it as requiring support for resource injection, postconstruct/predestroy.

Which is correct?



 Comments   
Comment by Shing Wai Chan [ 01/May/13 03:48 AM ]

The latter should be correct according to the description in 15.5.15 of Servlet 3.1.

Comment by janbartel [ 01/May/13 06:55 AM ]

I don't think that clarifies things, actually.

Section 15.5 of the servlet spec is entitled "Annotations and Resource Injection", yet the table 15.1 in that section is titled "Components and Interfaces supporting Annotations and Dependency Injection". Shouldn't that title be Resource injection rather than Dependency injection?

Section 15.5.15 of the servlet spec refers specifically instead to Context and Dependency Injection, not resource injection.

It seems to me that the JavaEE spec section 5.2.5 says explicitly that HttpUpgradeHandler needs to support annotations for Resource injection (and PostConstruct/PreDestroy), and also Context and Dependency injection iff CDI is enabled. So, the servlet spec needs to:

1. change the title of table 15.1 to refer to Resource injection, not Dependency injection (which is covered by sec 15.5.15)
2. add HttpUpgradeHandler to table 15.1

regards
Jan

Comment by Shing Wai Chan [ 01/May/13 04:37 PM ]

In my previous comment, I don't mean it is clarified. We will work on this.





[SERVLET_SPEC-73] Provide a way to find out mapping type used for selecting Servlet Created: 22/May/13  Updated: 09/Oct/13

Status: Open
Project: servlet-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Major
Reporter: arjan tijms Assignee: Rajiv Mordani
Resolution: Unresolved Votes: 3
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: ease-of-use ease_of_development
Participants: arjan tijms and Rajiv Mordani

 Description   

Section 12.2 of the Servlet spec defines how a request can be mapped to a Servlet in several ways, namely path mapping, extension mapping, a default mapping and an exact mapping.

A Servlet however can't easily find out which of the several mapping variants was used by the container to invoke it.

Knowledge of the mapping that was used is needed for several situations. E.g. In some frameworks (among which JSF) a Servlet can be mapped in several ways and the framework needs to reverse engineering the mapping using several tricks in order to distill the core requested page. E.g. extract /foo from any of /faces/foo.xhtml, /foo.xhtml and /foo.jsf.

Another case is when using both a default and another mapping for the same Servlet, such that this Servlet can handle "virtual resources" in a special way. E.g. the FacesServlet from JSF could be mapped to both *.xhtml and /, where a Filter filtering exactly the FacesServlet could intercept a request like /foo.bar, modify the request dynamically and continue the filtering chain.

Although there are workarounds for most cases, they aren't always the most obvious way to do things.

I therefor would like to propose to add a method to e.g. HttpServletRequest that code can use to find out which mapping variant was used for the current request processing.



 Comments   
Comment by arjan tijms [ 02/Jun/13 02:06 PM ]

In addition to what was primarily requested in this issue, it might also be useful to have a method on e.g. ServletContext where a URL or URI can be given as input and the mapping (if any) that the Servlet Container would use is then returned.





[SERVLET_SPEC-74] HttpServletResponse#sendRedirect(String) could use some improvement; needs 301/302/303 support; needs way to set request body Created: 25/May/13  Updated: 09/Oct/13

Status: Open
Project: servlet-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: Nick Williams Assignee: Shing Wai Chan
Resolution: Unresolved Votes: 1
Remaining Estimate: 1 day
Time Spent: Not Specified
Original Estimate: 1 day

Tags: http response redirect permanent get 301 302 303
Participants: Nick Williams and Shing Wai Chan

 Description   

Currently, HttpServletResponse#sendRedirect(String) specifies the following hard-wired behavior that cannot be changed:

  • Send the redirect using status code 302 Found and the Location header.
  • Clear the buffer and set the response body to a short hypertext note with a hyperlink to the new URI.

I have three issues with this behavior that I summarize below, and at the bottom I propose a solution:

Issue 1

RFC 2616, says the following about 302 Found:

If the 302 status code is received in response to a request other than GET or HEAD, the user agent MUST NOT automatically redirect the request unless it can be confirmed by the user, since this might change the conditions under which the request was issued.

Note: RFC 1945 and RFC 2068 specify that the client is not allowed to change the method on the redirected request. However, most existing user agent implementations treat 302 as if it were a 303 response, performing a GET on the Location field-value regardless of the original request method.

The two keys here are 1) that the spec says browsers MUST NOT automatically redirect the request and 2) that there could be some browsers that send the second request with the original method (POST, PUT, etc.).

As an application not concerned with legacy HTTP/1.0 user-agents and more concerned with ensuring that user agents do not prompt the user for permission to redirect and do not redirect using a POST or a PUT, etc., I prefer to use the 303 See Other response as opposed to the 302 Found response:

The response to the request can be found under a different URI and SHOULD be retrieved using a GET method on that resource. This method exists primarily to allow the output of a POST-activated script to redirect the user agent to a selected resource. ... The 303 response MUST NOT be cached, but the response to the second (redirected) request might be cacheable.

Issue 2

As an application that has recently been refactored, I want to be able to easily send a permanent redirect to users for old URLs that have been removed and should be changed. This can be achieved with the 301 Moved Permanently response:

The requested resource has been assigned a new permanent URI and any future references to this resource SHOULD use one of the returned URIs. Clients with link editing capabilities ought to automatically re-link references to the Request-URI to one or more of the new references returned by the server, where possible. ... The new permanent URI SHOULD be given by the Location field in the response. Unless the request method was HEAD, the entity of the response SHOULD contain a short hypertext note with a hyperlink to the new URI(s). ... If the 301 status code is received in response to a request other than GET or HEAD, the user agent MUST NOT automatically redirect the request unless it can be confirmed by the user, since this might change the conditions under which the request was issued.

Issue 3

The exact wording of the short hypertext response included with the current 302 Found responses is not consistent across containers. As an application developer that cares about branding and consistency, I would like to be able to customize this text within my code and do so in a way that is consistent across all containers.

Recommendation

I believe the following additions to the Servlet API will greatly improve the current HttpServletResponse#sendRedirect(String) and satisfy the needs outlined here.

New HttpRedirectType Enum
public enum HttpRedirectType {
    /*
     * Indicates that the {@code 301 Moved Permanently} status should be used.
     * Could alternatively be called MOVED_PERMANENTLY.
     */
    PERMANENT,

    /*
     * Indicates that the {@code 302 Found} status should be used.
     * Could alternatively be called FOUND.
     */
    TEMPORARY_SAME_METHOD,

    /*
     * Indicates that the {@code 303 See Other} status should be used.
     * Could alternatively be called SEE_OTHER.
     */
    TEMPORARY_USE_GET;
}
Additions to HttpServletResponse
public interface HttpServletResponse {
...
    void sendRedirect(String location, HttpRedirectType type);

    void sendRedirect(String location, boolean replaceBuffer);

    void sendRedirect(String location, HttpRedirectType type, boolean replaceBuffer);
...
}
  • If replaceBuffer is true, the container should clear the buffer and replace it with the data set by this method. If replaceBuffer is false, the container should send the existing buffer and should not add to it (even if it is empty) or remove from it.
  • The existing sendRedirect(String) should call sendRedirect(location, HttpRedirectType.TEMPORARY_SAME_METHOD, true) to preserve current behavior.
  • The new sendRedirect(String, HttpRedirectType) should call sendRedirect(location, type, true) to use the default response body.
  • The new sendRedirect(String, boolean) should call sendRedirect(location, HttpRedirectType.TEMPORARY_SAME_METHOD, replaceBuffer) to use the default 302 Found response.





[SERVLET_SPEC-75] Multipart part without filename must make part contents available as a string in parameters Created: 11/Jun/13  Updated: 09/Oct/13

Status: Open
Project: servlet-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: janbartel Assignee: Rajiv Mordani
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: janbartel, kchung, markt_asf and Rajiv Mordani

 Description   

Given that the MultiPartConfig allows for setting a maximum threshold after which part contents must be written to a file, it is odd that the spec also says that parts that don't explicitly include a filename must also make their contents available as a String in the params. The max threshold appears to be a good feature to avoid denial of service attacks via uncontrolled memory use, however having the requirement to put the content straight back into memory negates that. So a malicious client can simply not send a filename in the part content disposition and cause memory issues on the server side.

Would not a better solution be to make the name of the file to which the part was written available in the parameters? Only if the part was not written to a file would the part contents be available in the parameters.



 Comments   
Comment by kchung [ 11/Jun/13 09:24 PM ]

You are right in that the spec does not specify the behavior for getParameter and getParameterValues when a multipart content size exceeds the threshold.

It may be enough for the spec to say that getParameter are only guaranteed to return the content when the threshold is not reached, and leave the behavior undefined otherwise. In reality, we don't expect anybody to use this method to get BIG multipart files.

If we are to return the name of a file like you suggested, we'll need another way to tell us that a file name (instead of its content) is being returned. Don't think it's worth the trouble.

Comment by markt_asf [ 11/Jun/13 09:32 PM ]

The spec also doesn't state that containers should place limits on the size of POST requests. However, every container does to protect against a DoS. This is no different.

Tomcat addresses this issue by applying its standard POST limits to data that is processed via MultiPartConfig but ends up in the parameter map. Other containers will probably take a different approach but I think this falls firmly in the implmentation specific category.





[SERVLET_SPEC-78] Clarify welcome-files defined in fragments Created: 20/Aug/13  Updated: 09/Oct/13

Status: Open
Project: servlet-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: janbartel Assignee: Shing Wai Chan
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: janbartel and Shing Wai Chan

 Description   

Considering the definition of welcome-files, the 3.1 specification says that:

pg 8-79: The web.xml of the web application has the highest precedence when resolving conflicts between the web.xml, web-fragment.xml and annotations.

pg 8-79: a. Configuration settings in web fragments are used to augment those specified in the main web.xml in such a way as if they had been specified in the same web.xml.

pg 9-80: g. After the above conflicts have been resolved, these additional rules are applied
i. Elements that may be declared any number of times are additive across the web-fragments in the resulting web.xml. For example, <context-param> elements with different <param-name> are additive.
ii. Elements that may be declared any number of times, if specified in the web.xml overrides the values specified in the web-fragments with the
same name.
iii. If an element with a minimum occurrence of zero, and a maximum occurrence of one, is present in a web fragment, and missing in the main
web.xml, the main web.xml inherits the setting from the web fragment. If the element is present in both the main web.xml and the web fragment, the configuration setting in the main web.xml takes precedence. For example, if both the main web.xml and a web fragment declare the same servlet, and the servlet declaration in the web fragment specifies a <load-on-startup> element, whereas the one in the main web.xml does not, then the <load-on-startup> element from the web fragment will be used in the merged web.xml.

pg 8-81 v. <welcome-file> declarations are additive.

Therefore, what should happen in the following situations:

1. web.xml defines a list of welcome-files and a fragment-web.xml also defines a list of welcome-files. Are the ones from the fragment additive or does web.xml take precedence?

2. the servlet container provides a default set of welcome-files, the web.xml does NOT define any welcome-files, but a fragment-web.xml defines a different list. Should the final list of welcome files contain the union of those defined by the servlet container and the fragment, or only those defined by the fragment.






[SERVLET_SPEC-82] Clarify my responsibilities when I use Threadlocal variables in my Servlet. Created: 07/Oct/13  Updated: 09/Oct/13

Status: Open
Project: servlet-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: dtbullock Assignee: Shing Wai Chan
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: dtbullock, markt_asf and Shing Wai Chan

 Description   

A typical Servlet container services requests from a pool of threads. The Servlet container controls the lifecycle of those threads.

This creates a problem when my servlet (or a library which my servlet relies on) uses Threadlocal variables. For Tomcat, it means that when the context is undeployed, it has to check the viability of the threads in the pool to see if my code has 'polluted' them with Threadlocals. For example, it gives a warning like the following:

SEVERE: The web application [] created a ThreadLocal with key of type [org.apache.xmlbeans.impl.store.CharUtil$1] (value [org.apache.xmlbeans.impl.store.CharUtil$1@2aace7a7]) and a value of type [java.lang.ref.SoftReference] (value [java.lang.ref.SoftReference@3d9c9ad4]) but failed to remove it when the web application was stopped. Threads are going to be renewed over time to try and avoid a probable memory leak. Dec 13, 2012 12:54:30 PM org.apache.catalina.loader.WebappClassLoader checkThreadLocalMapForLeaks

Is this really an exceptional situation though? Can't I expect that the container will do as Tomcat has done, without feeling the need to blame me for it? Even if I did have the opportunity to provide some kind of 'thread-will-no-longer-perform-work-for-this-webapp' hook, I wouldn't necessarily be able to clean up - sometimes it is 3rd-party libraries which use Threadlocal.

See the question here for more discussion if you like.



 Comments   
Comment by markt_asf [ 07/Oct/13 09:18 AM ]

If an application uses a ThreadLocal within a request then the application should ideally clean up that ThreadLocal before the request completes as there is no guarantee that the application will ever see that thread again. However, libraries often use ThreadLocals to retain expensive to create objects across requests. This makes clean-up more difficult although libraries that do this should also clean-up after themselves.

I'd have no objection to the requirement that code that creates a ThreadLocal is responsible for cleaning up that ThreadLocal when it is no longer required being spelt out in the Servlet spec.

I would argue that many uses of a ThreadLocal would be better implemented in a container environment by the use of a pool of objects bound to the ServletContext.

Comment by dtbullock [ 07/Oct/13 04:47 PM ]

As an app-author, I don't mind providing a handler with a signature like void thisThreadIsBeingRetired() to try and clean up as best I can. However, please note that:

  1. yes, I'd probably instead bind object pools to the ServletContext ... in my code;
  2. I'd only be trying to clean up after 3rd-party libraries;
  3. those 3rd party libraries:
    1. might not provide a way for me to say "hey, clean up the thread"
    2. might be using ThreadLocal for purposes other than object-pooling

As such, putting the responsibility on me (even with a handler to make it possible at all), is a half-way measure.

I'd rather not have to do anything, anyhow.

In the ultra-big picture of things, why would a container permit worker-threads to visit multiple ServletContexts over time and allow ThreadLocals to be set, yet have no way to perform reliable clean-up when the association between the worker-thread and the ServletContext is broken?





[SERVLET_SPEC-83] ServletContext#getInitParameter with null parameter Created: 09/Oct/13  Updated: 09/Oct/13

Status: Open
Project: servlet-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: Shing Wai Chan Assignee: Shing Wai Chan
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: Shing Wai Chan

 Description   

In the javadoc of ServletContext#getInitParameter, we have

Returns a String containing the value of the named context-wide initialization parameter, or null if the parameter does not exist.

What happens when the name parameter is null? Should we throw NPE?

Similar issue for #getAttribute?
We would like to have a more consistence answer for these?






[SERVLET_SPEC-86] Support the specification of a content-encoding header for a resource based on file extension Created: 29/Dec/13  Updated: 30/Dec/13

Status: Open
Project: servlet-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Major
Reporter: markt_asf Assignee: Unassigned
Resolution: Unresolved Votes: 1
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: DaveLaw and markt_asf

 Description   

This arose from this discussion on the Tomcat users mailing list:
http://tomcat.markmail.org/thread/6x7izjf7ltphhh7r

Compressed SVG files (*.svgz) require that the server sets the Content-Encoding header so that the user agent correctly renders the response.

I would like to see the Servlet specification extended to allow applications to specify a Content-Encoding header for resources with a given file extension.

Any setting of the Content-Encoding on the response would have to be mindful of any Accept-Encoding header sent by the user agent and the requirements of RFC 2616 section 14.3.

This is very like the <mime-mapping> element currently used to configure Content-Type.

I see two possible options:

1. Add support for something along these lines
<encoding-mapping>
<extension>svgz</extension>
<encoding>gzip</encoding>
</encoding-mapping>

2. Extend <mime-mapping> along these lines:
<mime-mapping>
<extension>svgz</extension>
<mime-type>image/svg+xml</mime-type>
<encoding>gzip</encoding>
</mime-mapping>

The second solution seems simpler but <mime-mapping> element would no longer be limited to MIME type mapping. The first solution is probably a better option.



 Comments   
Comment by DaveLaw [ 30/Dec/13 09:44 AM ]

I believe "The second solution" is better:
<mime-mapping>
____<extension>svgz</extension>
____<mime-type>image/svg+xml</mime-type>
____<encoding>gzip</encoding> <!-- optional -->
</mime-mapping>
:
Unless there are overwhelming reasons to do so, it doesn't make sense
to maintain two separate lists, both with the same "primary key" (<extension>),
it would just make things (even) more confusing.
Of course, the <encoding> attribute should be optional.
And of course, it could perhaps be called, for example, <content-encoding>
:
I hope this can be resolved quickly, as I see the whole future of SVG Graphics
threatened by the patchwork implementation we've seen to date, particularly as
"plain-text" SVG's are so bloated, making compression very important.





[SERVLET_SPEC-87] Multipart request processing in a Filter should be possible but is not defined Created: 30/Jan/14  Updated: 30/Jan/14

Status: Open
Project: servlet-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major
Reporter: rstoyanchev Assignee: Unassigned
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: rstoyanchev

 Description   

The section on file uploads specifies that the servlet container provides multipart/form-data processing if the Servlet is annotated with @MultipartConfig or the deployment descriptor contains a multipart-config element. Then the Servlet can use the HttpServletRequest getParts and getPart methods.

A Filter should also be able to call getParts but there is no way for a filter to be configured like a Servlet with multiple config markers.

An important use case to point out is providing CSRF protection (typically done with a Servlet) for multipart requests where the filter needs to access information about what parts are submitted in order to validate the request.



 Comments   
Comment by rstoyanchev [ 30/Jan/14 08:26 PM ]

Correction to the above description. I meant to write (replace Servlet with Filter):

"An important use case to point out is providing CSRF protection (typically done with a Filter)..."





[SERVLET_SPEC-81] Clarify to users that the container will ensure work done in Servlet#init(ServletConfig) will be visible to threads which later invoke service methods. Created: 07/Oct/13  Updated: 09/Oct/13

Status: Open
Project: servlet-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Minor
Reporter: dtbullock Assignee: Rajiv Mordani
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: dtbullock, markt_asf, Rajiv Mordani and Shing Wai Chan

 Description   

As a longtime user of the Servlet specification, I have recently become more aware of thread-safety concerns, and when making my last servlet, I realised that if doGet() and friends are invoked from a thread pool, they are only guaranteed to see assignments I make in init(ServletConfig) if someone else has taken adequate care that the work done by that thread is visible to others.

Presumably, containers have in fact done this for nearly two decades. But it would be nice to have it spelled out somewhere, so that I can rely on this behaviour, and don't need to second-guess the environment and perform my own locking/synchronization.



 Comments   
Comment by markt_asf [ 07/Oct/13 09:07 AM ]

This looks like an application concern rather than a container concern to me.

The container will guarantee that init(ServletConfig) completes successfully before processing any requests (as per the Javadoc for init) but makes no other guarantees.

How do you propose that the container ensures that "work" completed in init() is visible to all the request processing threads?

Comment by dtbullock [ 07/Oct/13 04:01 PM ]

That's just the point - the spec needs to provide a slightly stronger guarantee, and say that the end of init(ServletConfig) 'happens before' invocations of doGet() and friends, in the sense that it is defined in section 17.4.5 of the JLS

Without this guarantee, javax.servlet.GenericServlet by definition has a threading bug, because it does not synchronize access to the 'config' field.

I'm not a container-author nor an expert in the Java Memory Model, and I'm not asking for the spec to proscribe a particular mechanism. I just need the spec to relieve me of the responsibility. The beauty of the Servlet spec is that I don't have to think about concurrency matters and can basically pretend I'm in a single-threaded environment for most use-cases. However, when I do think about it, I want to be sure I'm thinking about it right.

However, I believe that the requirement could be satisfied by ensuring that worker-threads are forced to lock the same object-monitor which a given Servlet's initializer-thread unlocked, before they become eligible to handle requests for that Servlet. They need not lock it every time they need to invoke a service-method - just when they are first given a reference to the properly-initialized Servlet. This is a pretty natural way to arrange for thread co-operation, and probably happens de-facto all the time anyway. Hence this amendment would likely not put any further obligations on container-authors.

Comment by Shing Wai Chan [ 07/Oct/13 04:50 PM ]

In javadoc of Servlet#init(ServletConfig), we have
"The servlet container calls the init method exactly once after instantiating the servlet. The init method must complete successfully before the servlet can receive any requests."

This guarantees that the #init is invoked before #doGet.

Comment by dtbullock [ 07/Oct/13 05:38 PM ]

That would be entirely adequate if the servlet container calls init() and services requests using the same thread. However, containers do not necessarily do this. Therefore, the spec needs to specify whether the container-implementer or the servlet-author is responsible for handling the resultant thread-safety issue.





[SERVLET_SPEC-84] Problems with links in the Servlet 3.1 Spec Created: 21/Nov/13  Updated: 21/Nov/13

Status: Open
Project: servlet-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: Arend v. Reinersdorff Assignee: Unassigned
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: Arend v. Reinersdorff

 Description   

Broken links to java.sun.com:
page 6 - http://java.sun.com/products/servlet - new: http://www.oracle.com/technetwork/java/index-jsp-135475.html
page 6 - http://java.sun.com/javaee/ - new: http://www.oracle.com/technetwork/java/javaee/overview/index.html
page 7 - http://java.sun.com/xml - ?
page 61 - http://java.sun.com/products/jsp - new: http://www.oracle.com/technetwork/java/index-jsp-138231.html
page 124 - http://java.sun.com/products/jsp - new: http://www.oracle.com/technetwork/java/index-jsp-138231.html
page 127 - http://java.sun.com/j2se/1.4/docs/guide/extensions/ - new: http://docs.oracle.com/javase/7/docs/technotes/guides/extensions/index.html

Typo, one 'w' too many
page 7 - http://wwww.ietf.org/rfc/

Closing bracket should not be included in link when clicked:
page 207 - http://jcp.org/jsr/detail/109.jsp]

Example links should use example.com instead of real domains:
page 53, 123 - http://www.mycorp.com/catalog - better: http://www.example.com/catalog
page 82 - http://www.myserver.com/catalog/index.html;jsessionid=1234 - better: http://www.example.com/catalog/index.html;jsessionid=1234
page 238 - http://java.sun.com/products/servlet/index.html - better: http://java.example.com/products/servlet/index.html
page 238 - https://javashop.sun.com/purchase - better: https://example.com/purchase






[SERVLET_SPEC-85] Example deployment descriptors still use version 2.5 instead of current version Created: 21/Nov/13  Updated: 21/Nov/13

Status: Open
Project: servlet-spec
Component/s: None
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Minor
Reporter: Arend v. Reinersdorff Assignee: Unassigned
Resolution: Unresolved Votes: 0
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags:
Participants: Arend v. Reinersdorff

 Description   

Servlet 3.1 Spec
page 179, 14.5.1 A Basic Example
page 180, 14.5.2 An Example of Security

The XML schema declarations are hard to remember. It would be nice to have a working example for the current version in the spec.






Generated at Thu Apr 17 06:08:46 UTC 2014 using JIRA 4.0.2#472.