[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: 21/Aug/14

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

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

Tags: order, servlet-container-initializer, web-fragment

 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 ]

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 ]

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 ]

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-107] Expose tls_unique as request attribute Created: 25/Sep/14  Updated: 25/Sep/14

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

Type: New Feature Priority: Critical
Reporter: Ed Burns Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

>>>>> On Thu, 25 Sep 2014 11:32:41 -0400, Ron Monzillo said:

RM> In addition to the attributes currently required to be supported
RM> when a request has been received over a secure protocol, consider
RM> adding a requirement that that container make the value of
RM> tls_unique availbale via the required to be supported (SSL)
RM> attributes.

RM> tls_unique is defined in http://tools.ietf.org/html/rfc5929

RM> Access to this value will facilitate the practice of creating
RM> cookies and other session identifying tokens that are bound to a
RM> specific TLS connection (iow, that cannot be stolen and reused
RM> outside of the TLS connection under which they were established and
RM> returned).

RM> The attribute could be called: javax.servlet.request.tls_unique

RM> Note that support for this attribute above JSSE will require that
RM> the value of verifyData as conveyed in the TLS finished handshake
RM> message be available from the SSLSession object.



 Comments   
Comment by markt_asf [ 25/Sep/14 ]

What feature(s) does this enable that can't be implemented based on javax.servlet.request.ssl_session_id?

What benefits would this provide over an above using SSL based session tracking as per Servlet 3.1, section 7.1.2?





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

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: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: extension, future_release, mapping, matching, path, prefix, servlet

 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 ]

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-11] Clarification required for ServletContext.getRealPath and HttpServletRequest.getPathTranslated Created: 21/Sep/11  Updated: 21/Aug/14

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: Unassigned
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 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 ]

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 ]

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 ]

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 ]

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-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
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: FUTURE_RELEASE

 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 ]

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 ]

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 ]

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 ]

Adding it to the bucket of FUTURE_RELEASE





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

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: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 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 ]

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 ]

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 ]

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 ]

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 ]

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-2] Pluggable resource loaders Created: 14/Jun/11  Updated: 21/Aug/14

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: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

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

 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 ]

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 ]

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 ]

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 ]

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 ]

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 ]

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 ]

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

Comment by Eirik Bjørsnøs [ 15/Dec/11 ]

Patch implementing ResourceLoader support for Jetty 8

Comment by Eirik Bjørsnøs [ 15/Dec/11 ]

Updates to Jetty's 3.0 Servlet Spec module adding ResourceLoader





[SERVLET_SPEC-1] Improve HttpSession distribution semantics Created: 31/May/11  Updated: 21/Aug/14

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

Type: Improvement Priority: Major
Reporter: gregwilkins Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: FUTURE_RELEASE

 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 ]

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 ]

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 ]

Adding it to the bucket of FUTURE_RELEASE





[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
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: FUTURE_RELEASE

 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 ]

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: 21/Aug/14

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

Type: Improvement Priority: Major
Reporter: markt_asf Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 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 ]

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 ]

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 ]

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-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
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: FUTURE_RELEASE

 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 ]

>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 ]

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 ]

>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 ]

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 ]

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 ]

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 ]

Adding it to the bucket of FUTURE_RELEASE





[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
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 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 ]

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

Comment by monzillo [ 10/Jan/13 ]

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 ]

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 ]

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 ]

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 ]

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-20] Clarify implicit mappings and welcome file behaviour Created: 07/Oct/11  Updated: 21/Aug/14

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

Type: Improvement Priority: Major
Reporter: markt_asf Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 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 ]

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-18] Clarify behaviour of getRequestURI(), getContextPath(), getServletPath() and getPathInfo() Created: 07/Oct/11  Updated: 21/Aug/14

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

Type: Improvement Priority: Major
Reporter: markt_asf Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 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 ]

Add getRequestURL() to the methods to be reviewed





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

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

Type: Improvement Priority: Major
Reporter: markt_asf Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

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



 Comments   
Comment by Rajiv Mordani [ 07/Feb/13 ]

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

Comment by markt_asf [ 07/Feb/13 ]

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

Comment by Rajiv Mordani [ 07/Feb/13 ]

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 ]

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





[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: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 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 ]

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-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
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 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 ]

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 ]

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
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 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-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
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 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-75] Multipart part without filename must make part contents available as a string in parameters Created: 11/Jun/13  Updated: 21/Aug/14

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

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


 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 ]

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 ]

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-74] HttpServletResponse#sendRedirect(String) could use some improvement; needs 301/302/303 support; needs way to set request body Created: 25/May/13  Updated: 07/Aug/14

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
Labels: None
Remaining Estimate: 1 day
Time Spent: Not Specified
Original Estimate: 1 day

Issue Links:
Related
is related to SERVLET_SPEC-100 sendRedirect permanent vs temporary a... Open
Tags: 301, 302, 303, get, http, permanent, redirect, response

 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-100] sendRedirect permanent vs temporary and GET vs preserve method Created: 28/Jul/14  Updated: 05/Sep/14

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

Type: Improvement Priority: Major
Reporter: gregwilkins Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to SERVLET_SPEC-74 HttpServletResponse#sendRedirect(Stri... Open

 Description   

RFCs 7231 and 7238 now define 8 different redirect codes, yet HttpServletResponse.sendRedirect only supports 302

An additional API should be consider that allows both permanent and temporary redirection as well as Moved (MAY change method) vs Redirect (MUST NOT change method) semantics

MOVED_PERMANENTLY = 301;
MOVED_TEMPORARILY = 302;
TEMPORARY_REDIRECT = 307;
PERMANENT_REDIRECT = 308;



 Comments   
Comment by markt_asf [ 05/Aug/14 ]

See also SPEC-74.

Comment by markt_asf [ 05/Sep/14 ]

Also, RFC7231 now permits location headers ot use relative URLs whereas RFC2616 and the Servlet spec require them to be absolute. HttpServletResponse.sendRedirect() should be updated not to convert relative URLs to absolute.





[SERVLET_SPEC-99] RFC7238 Permanent Redirection 308 Created: 28/Jul/14  Updated: 21/Aug/14

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

Type: Improvement Priority: Major
Reporter: gregwilkins Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

https://datatracker.ietf.org/doc/rfc7238/ defines the 308 Permanent redirection status code. This should be defined as an SC_ static in the HttpServletResponse class.






[SERVLET_SPEC-98] Provide a way to abort a response and close the underlying connection Created: 25/Jul/14  Updated: 21/Aug/14

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

Type: New Feature Priority: Major
Reporter: simonebordet Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

In the context of writing a reverse proxy using the Servlet API, this situation may happen:

  • The proxy proxies the request from client to server.
  • The server replies with headers and partial content
  • The proxy receives the headers and the partial content from the server, and relays both to the client; in doing so, the response from proxy to client is committed.
  • The server stops sending data.
  • The proxy times out the exchange with the server.
  • At this point, the proxy must signal to the client that something went wrong with the server; however, the proxy-to-client response is already committed, so the proxy must just abruptly close the connection.

There is no standard Servlet API to perform this abrupt close.

Closing the ServletOutputStream would probably just finish to send buffered data (or the terminator chunk in case of chunked content), which is not good as the client may think to have received the whole content, so it's not a viable solution.

There is a real need to close the connection, but the proxy cannot add Connection:close since the response is already committed.

In case of synchronous handling, the proxy may throw an exception, which would be interpreted by the Servlet Container as an indication to close the connection, but this solution does not work in the asynchronous case, where an external thread is writing the failure to the client.

A new API for this functionality should be added, covering both the synchronous case and the asynchronous case, for example:

// Fail the response to the client.
HttpServletResponse response = ...;
if (response.isCommitted())
{
    response.abort(); // <-- new API
    asyncContext.complete();
}
else
{
    response.resetBuffer();
    response.setStatus(503);
    response.setHeader("Connection", "close");
    asyncContext.complete();
}


 Comments   
Comment by gregwilkins [ 29/Jul/14 ]

This could potentially be achieved by specifying that abrupt close is the defined action if sendError is called on a committed response. The example code then just becomes:

// Fail the response to the client.
HttpServletResponse response = ...;
try

{response.sendError(503);}

finally

{asyncContext.complete();}
Comment by markt_asf [ 05/Aug/14 ]

+1 to sendError() on a committed response triggering an abrupt close. This is what Tomcat does currently.





[SERVLET_SPEC-96] isSecure should not trust scheme Created: 25/Jul/14  Updated: 21/Aug/14

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

Type: Improvement Priority: Major
Reporter: gregwilkins Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

servlet 4.0 http2


Tags: 4_0

 Description   

With http1, the scheme was not transported with the request (except for proxies), so it was the origin server that set if the scheme is http or https.

With http2, the scheme will be transported with the request, so it is possible for a https request to arrive over a plain text connection and for http to arrive over a TLS connection. Essentially scheme has become a user provided value rather than an origin server determined one.

The description of isSecure should be improved so that implementations do more than just return "https".equals(getScheme()). Implementations should check that https requests have a suitable secure context - which may be a TLS connection or the presence of headers or other out of band information provided by a TLS offloader (eg access to a protected port might be sufficient to indicate the request came from a secure path).






[SERVLET_SPEC-94] Clarify the legality of replacing the Thread Context ClassLoader Created: 18/Jul/14  Updated: 21/Aug/14

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

Type: Improvement Priority: Major
Reporter: Ed Burns Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Section 10.7.2 Web Application Class Loader states

An implementation MUST also guarantee that for every web application deployed in a container, a call to Thread.currentThread.getContextClassLoader() MUST return a ClassLoader instance that implements the contract specified in this section. Furthermore, the ClassLoader instance MUST be a separate instance for each deployed web application. The container is required to set the thread context ClassLoader as described above before making any callbacks (including listener callbacks) into the web application, and set it back to the original ClassLoader, once the callback returns.

Consider clarifying the legality and constraints on application code that calls Thread.setContextClassLoader().






[SERVLET_SPEC-92] The default charset of ISO-8859-1 has been removed. The default is whatever the media type says. Created: 08/Jul/14  Updated: 21/Aug/14

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

Type: Improvement Priority: Major
Reporter: Ed Burns Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

According to Phil Hunt's blog entry, <https://blogs.oracle.com/fusionmiddleware/entry/standards_corner_ietf_revisits_http> there are a number of improvements in the recent HTTP 1.1 JSRs that should be investigated for their impact on Servlet.

The default charset of ISO-8859-1 has been removed. The default is whatever the media type says.

Section 5.5 states:

If the servlet does not specify a character encoding before the getWriter method of the ServletResponse interface is called or the response is committed, the default ISO-8859-1 is used.

This text needs to be updated to reflect the changes in RFC 7231 http://tools.ietf.org/html/rfc7231



 Comments   
Comment by markt_asf [ 05/Aug/14 ]

I recall - although I can't find a reference right now - that Tomcat had a request to add an optional default encoding element to mime-mapping. That is one possible implementation option.





[SERVLET_SPEC-91] Discourage Basic Authentication Created: 08/Jul/14  Updated: 21/Aug/14

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

Type: Improvement Priority: Major
Reporter: Ed Burns Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

According to Phil Hunt's blog entry, <https://blogs.oracle.com/fusionmiddleware/entry/standards_corner_ietf_revisits_http> there are a number of improvements in the recent HTTP 1.1 JSRs that should be investigated for their impact on Servlet.

Consider logging a message at deployment time if the use of basic authentication is detected.



 Comments   
Comment by markt_asf [ 10/Jul/14 ]

Why single out basic authentication? It is no better than form authentication from a security perspective and both are fine if used over SSL.





[SERVLET_SPEC-104] inconsistent async-supported ordering for filters and servlets Created: 27/Aug/14  Updated: 27/Aug/14

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

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


 Description   

The schema for servlet and filters is a sequence rather than a group, so when validating, the order of the elements is important.

However, async-supported is inconsistent, as it is before init-params in filters, but after them in servlets.






[SERVLET_SPEC-109] AsyncContext#complete will not take effect Created: 09/Oct/14  Updated: 09/Oct/14

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

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


 Description   

In Servlet 3.1 spec, we have the following for AsyncContext#complete:
If this method is called before the container-initiated dispatch that called startAsync has returned to the container, then the call will not take effect until after the container-initiated dispatch has returned to the container. Invocation of the AsyncListener.onComplete(AsyncEvent) will also be delayed till after the
container-initiated dispatch has returned to the container.

Precisely, what does the "will not take effect" means?
Notice that there are similar paragraph for AsyncContext#dispatch.

What happens when we do the following within the Servlet#service:
asyncContext.complete() and then asyncContext.dispatch()?

We need to clarify the meaning of "will not take effect" in these two paragraphs.






[SERVLET_SPEC-108] Error pages for non-GET methods Created: 09/Oct/14  Updated: 09/Oct/14

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

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


 Description   

If a request for a non-GET method (eg PUT, DELETE, MOVE) generates an exception or an error, then this could be mapped to an error page.

However it is likely that error page generation is unable to handle methods other that GET, HEAD and maybe POST (eg Default servlet should not return static content for a PUT request).

Perhaps we should specify that error dispatches should have their method changed to GET and the original method made available by a new ERROR_METHOD attribute?






[SERVLET_SPEC-103] AsyncContext ISE inconsistency Created: 08/Aug/14  Updated: 15/Sep/14

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

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


 Description   

The javadoc for when AsyncContext should throw an ISE is inconsistent:

getRequest()
IllegalStateException - if complete() or any of the dispatch() methods has been called in the asynchronous cycle

addListener(...)
IllegalStateException - if this method is called after the container-initiated dispatch, during which one of the ServletRequest.startAsync() methods was called, has returned to the container

So getRequest fails with an ISE immediately after dispatch or complete have been called (even if called in another thread), while addListener waits until after the current dispatch returns before throwing any ISE.

These should be consistent, because a filter that is trying to add a Listener may need to call getRequest in order to obtain the wrapped request. Currently there is a race for such code that will fail if another thread calls dispatch/complete before the thread dispatched to the filters/servlet has returned.



 Comments   
Comment by gregwilkins [ 08/Aug/14 ]

Note also, it needs to be clarified if getRequest() can be called during an onComplete callback (triggered by a call to complete()). Strictly speaking complete() "has been called", but getting the request is valuable in an onComplete callback for logging, and request attribute access.

Comment by gregwilkins [ 08/Aug/14 ]

On further analysis, I believe that throwing an ISE from getRequest() is unnecessary before the onComplete() callbacks have been called.

I have a use case where a onComplete callback is used to log a request/response as follows:

@Override
public void onComplete(AsyncEvent event) throws IOException

{ AsyncContextState context = (AsyncContextState)event.getAsyncContext(); Request request=context.getHttpChannelState().getBaseRequest(); Response response=request.getResponse(); _requestLog.log(request,response); }

If getRequest is unavailable once dispatch() has been called, then such use-cases will need to take copies of the request/response and create per request instances of the listener. This makes it pointless passing in the event to onComplete as it cannot be used to access anything about the request.

Comment by tremes [ 15/Sep/14 ]

Hi!
I could be wrong but I can see some next inconsistency. When I do this then the ISE is thrown:

public void onComplete(AsyncEvent event) {
       event.getAsyncContext().getResponse());
}

But what about this. Shouldn't be ISE thrown as well??

public void onComplete(AsyncEvent event) {
       event.getSuppliedResponse();
}




[SERVLET_SPEC-102] handling lenient query strings Created: 01/Aug/14  Updated: 21/Aug/14

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

Type: Improvement Priority: Major
Reporter: gregwilkins Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

The javadoc says that query string should not be decoded by the container. However, does that mean that the string has to be exactly what the container received?

Consider the URL

http://localhost:8080/hi?e=w%6fah dude

It has a space in the query that really should be encoded, but most containers are lenient.

But if the query string returned is "w%6fah dude", then this makes it difficult to use this query to reform new URIs as many libraries will error if the space is passed.

However, if the query string is simply encoded it will become: "w%256fah%20dude", which is also wrong.

Should we say that any container that does lenient parsing of the query string corrects those errors in the returned query string? So in this case getQueryString will return "w%6fah%20dude"?






[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: 4
Labels: None
Remaining Estimate: 1 hour
Time Spent: Not Specified
Original Estimate: 1 hour

Tags: servlet-context, session-timeout, sessions

 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 ]

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

Comment by kithouna [ 09/Aug/13 ]

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
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 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 ]

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

Comment by janbartel [ 01/May/13 ]

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 ]

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





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

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

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

n/a


Tags: matrixparameter, pathparameter, pathsegment, request

 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 ]

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 ]

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 ]

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-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
Labels: None
Remaining Estimate: 2 hours
Time Spent: Not Specified
Original Estimate: 2 hours
Environment:

n/a


Tags: multipart, progressbar, upload

 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 ]

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 ]

+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 ]

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 ]

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

Comment by Nick Williams [ 11/Mar/13 ]

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 ]

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-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
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: FUTURE_RELEASE, cors, security, servlet

 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-68] Change HttpSessionListener to extend new HttpSessionCreateListener, HttpSessionDestroyListener Created: 18/Mar/13  Updated: 21/Aug/14

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

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


 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-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
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 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: 21/Aug/14

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

Type: Improvement Priority: Major
Reporter: sslavic Assignee: Unassigned
Resolution: Unresolved Votes: 7
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: FUTURE_RELEASE

 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 ]

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
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: FUTURE_RELEASE

 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 ]

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 ]

Adding it to the bucket of FUTURE_RELEASE





[SERVLET_SPEC-40] ServletInputStream.readLine has several problems Created: 30/May/12  Updated: 21/Aug/14

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

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

servlet 3.0



 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: 22/Aug/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: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 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 ]

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 ]

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?

Comment by gregwilkins [ 22/Aug/14 ]

definite agree that using the request methods asychronously is not reliable.

I'm not sure that access should be prohibited, but the javadoc should at least point out that the values returned may change (due to dispatches) and that the memory barriers for such changes are undefined.





[SERVLET_SPEC-45] Access to connector/socket container info Created: 03/Sep/12  Updated: 21/Aug/14

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

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

Tags: FUTURE_RELEASE

 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 ]

Adding it to the bucket of FUTURE_RELEASE





[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: 14
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 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 ]

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 ]

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

Comment by jfarcand [ 24/Apr/13 ]

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 ]

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 ]

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 ]

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

Comment by rstoyanchev [ 10/Dec/13 ]

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-31] Async Request parameters Created: 27/Feb/12  Updated: 22/Aug/14

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

Type: Improvement Priority: Major
Reporter: gregwilkins Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 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 ]

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 ]

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?

Comment by gregwilkins [ 22/Aug/14 ]

very late response.

I don't see why a request can't be forwarded after async is started. It would be strange way to handle a request, but I see no reason for it to be prohibited.

But even if it can't be forwarded, it can be return from previous forwards after startAsync, so the values returned by the request.getXxx() methods will be volatile if access from an asynchronous thread.

Hence I believe the request attributes are the best way to obtain path information as they are immutable once set and thus thread safe.





[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
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: FUTURE_RELEASE

 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 ]

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 ]

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 ]

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
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: FUTURE_RELEASE

 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 ]

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 ]

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-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
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: FUTURE_RELEASE, security, web-a

 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 ]

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 ]

Adding it to the bucket of FUTURE_RELEASE





[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
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: FUTURE_RELEASE

 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 ]

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 ]

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 ]

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-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
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: FUTURE_RELEASE

 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 ]

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 ]

@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 ]

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 ]

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 ]

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 ]

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-60] Provide HttpServletRequestWrapper that minimizes effort required to override core data Created: 20/Feb/13  Updated: 21/Aug/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: Unassigned
Resolution: Unresolved Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 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-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
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: FUTURE_RELEASE

 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 ]

Adding it to the bucket of FUTURE_RELEASE





[SERVLET_SPEC-110] Verify that Async support works with CDI injection Created: 14/Oct/14  Updated: 14/Oct/14

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

Type: New Feature Priority: Major
Reporter: Ed Burns Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

This is a tracking issue for an issue in the CDI issue tracker to verify that CDI injection works in async servlets.

https://issues.jboss.org/browse/CDI-452






[SERVLET_SPEC-111] Clarify MultiPartConfig.fileSizeThreshold default value Created: 17/Oct/14  Updated: 17/Oct/14

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

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


 Description   

The default value for MultiPartConfig fileSizeThreshold is 0. Does that mean that a container must write the bytes to disk, or does it mean that the container should never write the bytes to disk?






[SERVLET_SPEC-89] Need clarification /enhancement to <distributable/> Created: 09/Jun/14  Updated: 21/Oct/14

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

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


 Description   

Suppose we have a war with one web-fragment as follows:
a) In web.xml, there is no <distributable/>.
b) In web-fragment.xml, there is a <distributable/>.
What is the resulting merged web.xml?

In g.iii. of 8-80 of Servlet 3.1, we have

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-onstartup>
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.

ix. The web.xml resulting from the merge is considered <distributable>
only if all its web fragments are marked as <distributable> as well.

And we have at most one <distributable/> according to descriptions in
schema:
The web-app element is the root of the deployment
descriptor for a web application. Note that the sub-elements
of this element can be in the arbitrary order. Because of
that, the multiplicity of the elements of distributable,
session-config, welcome-file-list, jsp-config, login-config,
and locale-encoding-mapping-list was changed from "?" to "*"
in this schema. However, the deployment descriptor instance
file must not contain multiple elements of session-config,
jsp-config, and login-config. When there are multiple elements of
welcome-file-list or locale-encoding-mapping-list, the container
must concatenate the element contents. The multiple occurence
of the element distributable is redundant and the container
treats that case exactly in the same way when there is only
one distributable.

So, the answer seems to be a <distributable/>.

In other words, if all the web fragment libraries are distributable.
Then so must the application be.

Since distributable element is an emptyType, it cannot be mark as not distributable.

I suggest to add an optional boolean attribute with default value true.
This allows user to specify explicitly whether the web app is distributable or not.



 Comments   
Comment by markt_asf [ 10/Jun/14 ]

It looks like the text for ix just needs some tweaks. The "as well." at the end suggests to me that it means the main web.xml and all the fragments need to be marked as distributable.

I suggest the following re-wording:

ix. The web.xml resulting from the merge is considered <distributable>
only if the main web.xml and all the web fragments are marked as <distributable>.

Comment by chemFelix [ 21/Oct/14 ]

This problem and the resulting implementation ( https://java.net/jira/browse/GLASSFISH-20917 ) are really blocking me. Why does it take so long to fix this? Of course, the impact of such change may be substantial, but it will still be if we wait for christmas. The fact that this particular bug appeared is acceptable, while the combination of the bug and the lack of any efforts to resolve it are not. Sorry for my harsh words.





[SERVLET_SPEC-113] Support newer http methods eg PATCH Created: 22/Oct/14  Updated: 22/Oct/14

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

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


 Description   

RFC 5789 defines the method "PATCH". http://tools.ietf.org/html/rfc5789

Its semantics seem similar to POST or PUT in that it provides content to the server. However, section 3, pg 24 does not permit a web server to parse form-url-encoded content unless:

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.

Thus, the spec needs to be updated to accommodate methods like PUT and the newer PATCH.






[SERVLET_SPEC-112] Character encoding of ServletOutputStream print methods Created: 21/Oct/14  Updated: 23/Oct/14

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

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


 Description   

The async API is only available on the output stream. Thus we have had a framework that used to do:

response.setContentType("application/json;charset=UTF-8");
...
response.getWriter().print("Ӝ");

convert to asynchronous style and now it does:

response.setContentType("application/json;charset=UTF-8");
...
response.getOutputStream().print("Ӝ");

This works fine on some containers (eg Jetty), but apparently many containers do not respect the encoding set by the setContentType. They either convert the character as ISO8859-1 or if the first character is UTF-8, they throw a CharacterEncoding exception.

We have also seen at least one container handle the following writes out of order:

response.getOutputStream().print("one");
response.getOutputStream().write("two".getBytes(UTF_8);
response.getOutputStream().print("three");

As the async API will now make more character oriented frameworks use the output stream, I believe that we need to clarify the semantics of the ServletOutputStream print method so that it:

+ is definitely mix and match with write - so we must say that print cannot buffer any data.
+ respects the character encoding set on the response



 Comments   
Comment by markt_asf [ 22/Oct/14 ]

I assume you mean ServletOutputStream, not HttpOutputStream.

No issue with saying print cannot buffer data.

More than happy to see the spec be more explicit about char -> byte conversions. Respecting the character encoding set on the response works for synchronous and asynchronous cases but what about HTTP upgrade where there is no response? In this case the user just has the ServletOutputStream. I'm tempted to say add a setCharacterEncoding(String) method to ServletOutputStream but that then creates precedence issues with whatever is set on the Response for the synchronous and asynchronous cases. The precedence issue is solveable - it just adds complexity I'd rather avoid.

Comment by gregwilkins [ 22/Oct/14 ]

Ooops yes ServletOutputStream

For HTTP upgrade there is still a response as the upgrade has to be responded to before the upgrade takes place. So setting the character encoding on the response before getting the outputstream should work, if a little clumsy.

cheers

Comment by markt_asf [ 23/Oct/14 ]

I've updated the issue title and description to refer to ServletOutputStream

With respect to HTTP upgrade and setting the character encoding on the response before the upgrade, that only works if the encoding is known at that point. I don't know of a use case where the encoding is not known until after the upgrade but it doesn't seem unreasonable that there might be one.





[SERVLET_SPEC-114] Standardize authentication modules in Servlet Created: 31/Oct/14  Updated: 31/Oct/14

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

Type: Improvement Priority: Major
Reporter: arjan tijms Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: authentication, jaspic, jsr-196, security

 Description   

13.6.5 of the Servlet spec says that it's recommended that Servlet containers use the Servlet Container Profile of the Java Authentication SPI for Containers (aka JASPIC, i.e. JSR 196).

In order to facilitate portability and a steady base to build upon for the entire Java EE platform, I'd like to propose to change this from "recommended" to "mandated".



 Comments   
Comment by arjan tijms [ 31/Oct/14 ]

P.s, a change in section 15.3.3 is also needed.

This section now says that all Servlet containers must implement JASPIC in a Java EE product or a product that supports JASPIC.

For this section I'd like to propose removing the conditional so that the section simply holds for all Servlet containers.

The section in 15.3.3 now reads as follows:

In a Java EE product, or a product that includes support for The Java
Authentication SPI for Containers (JASPIC, i.e, JSR 196), all Servlet
containers MUST implement the Servlet Container Profile of the JASPIC
specification.

After the proposed change this would become:

All Servlet containers MUST implement the Servlet Container Profile of the JASPIC
specification.

For completeness, the section in 13.6.5 now reads:

To facilitate portable implementation and integration of additional container authentication
mechanisms, it is recommended that all Servlet containers implement the Servlet Container
Profile of The Java Authentication SPI for Containers

After the proposed change this would become:

To facilitate portable implementation and integration of additional container authentication
mechanisms, it is mandated that all Servlet containers implement the Servlet Container
Profile of The Java Authentication SPI for Containers





[SERVLET_SPEC-117] clarify request/response methods that can be called asynchronously Created: 03/Dec/14  Updated: 03/Dec/14

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

Type: Improvement Priority: Major
Reporter: gregwilkins Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

It is unclear from the current specification what request/response methods can be called from another thread when a request is in asynchronous mode (and also when the input/output is in asynchronous mode).

Examples that require clarification include when called by non-container threads include:
ServletResponse.sendError(...)
FilterChain.doFilter(...)
RequestDispatcher.forward(...)
ServletRequest.getParameter(...)

All of these methods may invoke container and/or application code that assumes blocking IO, so if for example the input stream has been put into async IO mode and getParameter is called, will the request body be correctly consumed?

Some of these methods assume a context for their dispatch, some of which may be established by using AsyncContext#start. Do these methods assume that #start has been called? should they check and effectively do a #start themselves? or are these methods just prohibited from use by non-container threads... in which case where do we specify this?






[SERVLET_SPEC-118] Replace and deprecate ServletRequest.getParameter for HttpServletRequest Created: 04/Dec/14  Updated: 04/Dec/14

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

Type: Improvement Priority: Major
Reporter: jgigov Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

As it stands now, getParameter is only useful for String parameters, making it useless for file uploads or just any multipart/* POST requests. I propose the adding following methods to the HttpServletRequest interface.

HttpServletRequest.java
public String getString(String parameterName);
public String[] getStrings(String parameterName);
public Integer getInt(String parameterName) ;
public Integer[] getInts(String parameterName);
public Long getLong(String parameterName);
public Long[] getLongs(String parameterName);
public Float getDouble(String parameterName);
public Float[] getDoubles(String parameterName);
public Double getDouble(String parameterName);
public Double[] getDoubles(String parameterName);
public Number getNumber(String parameterName);
public Number[] getNumbers(String parameterName);
public File getFile(String parameterName);
public File[] getFiles(String parameterName);
public Object getObject(String parameterName);
public Object[] getObjects(String parameterName);
public Map<String,Object[]> getParameterObjects();

By their very names, they are rather self-explanatory. Most of them are essentially parsers to convert from String to the desired object. They should throw NumberFormatException if it occurs, but otherwise behave same as getParameter and getParameterValues for consistency.

The part that requires most discussion, however is how will we get the original file name of uploaded files. There are several reasonable ways it can be done:

1. Have methods in the HttpServletRequest that return only the file name(s).
2. Define a new public (possibly static) class that is returned instead of File, that will contain original file name and the File object, or simply extends File and adds a method for the original name.
3. Define a naming convention to be used, from which the name can always be extracted (the least reasonable, in my opinion, but doable).
4. Define a private/protected class that extends File, but overrides toString() to return the original file name (the solution I used for our company project).

possibility1
public String getFileName(String parameterName);
public String[] getFileNames(String parameterName);

Additionally it might be nicer to have the possibility to return default values and simply have the ones without a defualt specifier overload to calling them with null as the default value.

HttpServletRequest.java
public String getString(String parameterName, String defaultReturn);
public Integer getInt(String parameterName, Integer defaultReturn) ;
public Long getLong(String parameterName, Long defaultReturn);
public Float getDouble(String parameterName, Float defaultReturn);
public Double getDouble(String parameterName, Double defaultReturn);
public Number getNumber(String parameterName, Number defaultReturn);
public Object getObject(String parameterName, Object defaultReturn);

It should also be clearly defined in the JavaDocs how a zero-length parameter sent by the user is treated. Whether it is returned as a zero-length String or null. As the JavaDocs for Java EE 7 stand right now, that is ambiguous and open to interpretation.

Implementing these changes will allow for standard parsers to process RFC 2388 multipart/form-data, the upcoming JSON form and possibly other standards (as there probably are).






[SERVLET_SPEC-73] Provide a way to find out mapping type used for selecting Servlet Created: 22/May/13  Updated: 21/Aug/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: Unassigned
Resolution: Unresolved Votes: 5
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Tags: ease-of-use, ease_of_development

 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 ]

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-120] ServletRequestListener methods and Threads Created: 17/Dec/14  Updated: 17/Dec/14

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

Type: Bug Priority: Major
Reporter: Ed Burns Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

JH> Dear Servlet experts,
JH> the behavior of javax.servlet.ServletRequestListener seems to be
JH> underspecified in Servlet 3.1 especially in case of asynchronous
JH> requests. I am seeking clarification for the case that follows.

JH> There two properties of ServletRequestListener invocation that a Servlet
JH> implementation may want to have:

JH> 1) requestInitialized()/requestDestroyed() are only called once per request

JH> This one simply says that the pair of
JH> requestInitialized()/requestDestroyed() methods of a given listener is
JH> not called more than once per a given request.

JH> 2) Symmetry with respect to the calling thread

JH> This property says that if the
JH> ServletRequestListener.requestInitialized() is called by a given thread
JH> (T1) then the corresponding ServletRequestListener.requestDestroyed()
JH> invocation is performed by the same thread (T1). This second property is
JH> very important for integration with various other
JH> frameworks/technologies as it allows them to set a ThreadLocal in
JH> requestInitialized() and remove it in requestDestroyed()

JH> Both these properties are achievable at the same time for synchronous
JH> Servlets. However, for asynchronous Servlets these properties are
JH> mutually exclusive. Most Servlet containers deal with this by
JH> sacrificing property (1) and only guarantee (2).

JH> I do not find the specification clear enough to tell which of the two
JH> options is the correct one.



 Comments   
Comment by Ed Burns [ 17/Dec/14 ]

JH> An example follows. Suppose we have a simple asynchronous servlet that:

JH> A1) Does initial processing of the request
JH> A2) Goes async (req.startAsync())
JH> A3) Spawns a new thread T that calculates something
JH> A4) The servlet exits

JH> B1) The spawn thread T calculates the value
JH> B2) Once the thread T finishes calculation, it dispatches back to
JH> Servlet container for rendering (e.g.
JH> ctx.dispatch("/asyncFinish?value=calculatedValue"))

JH> C1) Servlet container creates response and completes the request

JH> A1-A4 steps are performed by thread A that initially handles the
JH> request. B1 and B2 steps are performed by thread B spawned by a Servlet,
JH> C1 step is performed again by a Servlet container thread.

JH> Now the question arises: When and how should ServletRequestListener
JH> callbacks be invoked?

JH> Servlet containers that guarantee second of aforementioned properties,
JH> symmetry of the calling thread, do the following:

JH> Thread A calls ServletRequestListener.requestInitialized()
JH> A1, A2, A3 and A4 are performed
JH> Thread A calls ServletRequestListener.requestDestroyed()

JH> When the value is calculated by thread B and the request is dispatched
JH> to the Servlet container again:

JH> Thread C calls ServletRequestListener.requestInitialized()
JH> C1 is performed
JH> Thread C calls ServletRequestListener.requestDestroyed()

JH> Implementation such as this one:
JH> sacrifices property (1) - the pair of ServletRequestListener methods is
JH> called more than once for a given request - each time request is being
JH> worked on by Servlet container
JH> guarantees property (2) - symmetry of the calling thread - allows
JH> frameworks that depend on ThreadLocal to use ServletRequestListeners as
JH> reliable hooks

JH> Undertow, JBoss Web, Jetty and Grizzly all do this.

JH> Tomcat [1] uses an alternative implementation which simply does the
JH> following:

JH> 1) Thread A calls ServletRequestListener.requestInitialized()
JH> 2) the entire request is processed in threads A, B and C
JH> 3) Thread C calls ServletRequestListener.requestDestroyed()

JH> This implementation:
JH> guarantees property (1) - the pair of callbacks only called once
JH> sacrifices property (2) - as a result, a ThreadLocal set by
JH> ServletRequestListener.requestInitialized() will probably not be cleaned
JH> up in the corresponding ServletRequestListener.requestDestroyed() call
JH> as it is invoked in a different thread - making frameworks that work on
JH> all the other implementations leak on Tomcat

Comment by Ed Burns [ 17/Dec/14 ]

I found the following mentions in the
JH> specification:

JH> Table 11-3
JH> A servlet request has started being processed by Web components. -
JH> javax.servlet.ServletRequestListener
JH> Javadoc:
JH> A ServletRequest is defined as coming into scope of a web application
JH> when it is about to enter the first servlet or filter of the web
JH> application, and as going out of scope as it exits the last servlet or
JH> the first filter in the chain.

JH> Which all leave room for interpretation.

JH> The fact that two very different implementations of this behavior exist
JH> significantly reduces the usability of ServletRequestListener API by
JH> frameworks. I am therefore asking you for clarification of which one of
JH> these two implementations is correct and/or matches the best the
JH> original intention of specification authors and should be prefered.





[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: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 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 ]

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-122] Clarify session object (HttpSession instance) lifetime requirements Created: 03/Feb/15  Updated: 03/Feb/15

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

Type: Improvement Priority: Major
Reporter: VsevolodGolovanov Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

There is a practice of synchronizing on the session object. http://stackoverflow.com/a/616723/1341535 even mentions books advocating this.
The servlet specification is somewhat vague on what is the lifetime of a session instance. As seen in JAVASERVERFACES-3734, this part of 7.7.1 Threading issues:

Multiple servlets executing request threads may have active access to the same session object at the same time.

can be taken to mean that the HttpSession instance remains the same between requests.
There is also 7.3 Session scope:

HttpSession objects must be scoped at the application (or servlet context) level.

In actuality some servlet containers implement HttpSession as just a wrapper around the real session object, and create an instance of the wrapper for each request. I know that Undertow does this. Spring's utils mention that the same instance is not guaranteed, so there are probably others.

"Session object" is used quite liberally throughout the spec. Another example is in 7.7.2 Distributed Environments:

The Container Provider can ensure scalability and quality of service features like
load-balancing and failover by having the ability to move a session object, and its
contents, from any active node of the distributed system to a different node of the
system.

In this case session object definitely doesn't mean session instance. It's not clear what's the difference between a session object and session object's contents here. Seems like both refer to the same thing.

I suggest amending the quoted parts for clarity.






[SERVLET_SPEC-105] ServletContext.getRealPath(String) needs clarification Created: 01/Sep/14  Updated: 10/Feb/15

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

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


 Description   

The Javadoc for getRealPath() uses the term "virtual path" but doesn't define it anywhere. Clearly, the virtual path is relative to the context root but the following are not clear:

1. Must the path start with '/'?
2. If the path must start with '/', what happens if it does not?
3. If the path doesn't have to start with '/' how do you get from the provided path to a path relative to the content root?

My personal view is:
1. Yes.
2. Throw an IllegalArgumentException
3. N/A

One caveat to the above is that we might allow paths of "" which are treated as equivalent to "/".



 Comments   
Comment by markt_asf [ 10/Feb/15 ]

Ping. Does anyone else on the EG have a view on this?





[SERVLET_SPEC-125] typo in method signature of getServletRegistrations() in p4-37 Created: 18/Feb/15  Updated: 18/Feb/15

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

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


 Description   

In p4-37 of Servlet 3.1, we have Map<String, ? extends FilterRegistration> getServletRegistrations().
The method name should getFilterRegistrations().
There is a typo in description, too.






[SERVLET_SPEC-126] ServletContainerInitializer.onStartup() and descriptors version level? Created: 20/Feb/15  Updated: 26/Feb/15

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

Type: Bug Priority: Major
Reporter: Ed Burns Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Attachments: PNG File 20150220-1859-servlet-spec-126.png    

 Description   

I observe inconsistent behavior between GlassFish and WebLogic regarding the invocation of the onStartup() method of a ServletContainerInitializer implementation depending on the version level of the web.xml. On GlassFish 4.1, the onStartup() gets called regardless of the version level of the web.xml. On WebLogic it appears to only be called if the version is 3.0 or greater.

This indicates the need for clarity in the spec.



 Comments   
Comment by Ed Burns [ 20/Feb/15 ]

Section 1.6.1 Processing annotations says

In Servlet 2.5, metadata-complete only affected the scanning of
annotations at deployment time. The notion of web-fragments did not
exist in servlet 2.5. However in servlet 3.0 and later,
metadata-complete affects scanning of all annotations that specify
deployment information and web-fragments at deployment time. The version
of the descriptor MUST not affect which annotations you scan for in a
web application. An implementation of a particular version of the
specification MUST scan for all annotations supported in that
configuration, unless metadatacomplete is specified.

Comment by Ed Burns [ 21/Feb/15 ]

Table 8-1 (see attached image) also talks about descriptor version levels and annotation processing.

I would like to see some text that also says the onStartup() must be called regardless of version level.

Comment by Shing Wai Chan [ 21/Feb/15 ]

This is a more general question rather than onStartup().
The version of the web.xml just indicate the version of the schema. It does not say anything about the runtime.
So it is better to add text in a more general place rather than onStartup() only.

Comment by Ed Burns [ 26/Feb/15 ]

Another question.

Section 8.1 talks about the metadata-complete="true" value.

If "metadata-complete" is set to true, the deployment tool MUST ignore any servlet annotations that specify deployment information present in the class files of the application and web fragments.

I think it might be worthwhile to state that annotations defined outside of the servlet spec are not impacted by the metadata-complete=true rule.

Comment by Shing Wai Chan [ 26/Feb/15 ]

metadata-complete also take effect for other annotations outside servlet spec, for instance @Resource, etc.





[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
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 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.






[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
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 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-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: 21/Aug/14

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

Type: Improvement Priority: Minor
Reporter: dtbullock Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 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 ]

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 ]

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 ]

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 ]

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-115] Missing DTD in jar file Created: 04/Nov/14  Updated: 04/Nov/14

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

Type: Bug Priority: Minor
Reporter: paulmillar Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Previous versions of servlet-spec jar included several XML dtd documents as part of their contents:

paul@sparkplug:~$ jar tf ~/.m2/repository/javax/servlet/servlet-api/2.5/servlet-api-2.5.jar |grep dtd
javax/servlet/resources/XMLSchema.dtd
javax/servlet/resources/datatypes.dtd
javax/servlet/resources/web-app_2_2.dtd
javax/servlet/resources/web-app_2_3.dtd
paul@sparkplug:~$

With later versions of servlet-api, these dtd files are missing:

paul@sparkplug:~$ jar tf ~/.m2/repository/javax/servlet/javax.servlet-api/3.1.0/javax.servlet-api-3.1.0.jar|grep dtd
paul@sparkplug:~$

When included correctly, these files allow validating parsers to obtain the necessary DTD information from the jar file directly, without downloading them. This reduces pressure on the DTD host (java.sun.com), improves software performance and removes the necessity to have Internet access.

While the application can include the DTD files itself to achieve the same benefit, placing them within the servlet-spec jar file (as before) seems a reasonable trade-off.






[SERVLET_SPEC-119] Clarification of threading requirements of section 6.2.3 Created: 15/Dec/14  Updated: 19/Dec/14

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

Type: Improvement Priority: Minor
Reporter: Ed Burns Assignee: Ed Burns
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: 0 minutes
Time Spent: 40 minutes
Original Estimate: Not Specified


 Description   

>>>>> On Sat, 06 Dec 2014 00:14:51 +0000, Mark Thomas <markt@apache.org> said:

MT> Hi,
MT> Section 6.2.3 includes the following text:

Spec> A Filter and the target servlet or resource at the end of the
Spec> filter chain must execute in the same invocation thread.

MT> As a result of a bug raised against Apache Tomcat [1] I am seeking
MT> clarification of the meaning of that sentence.
MT>
MT> [1] https://issues.apache.org/bugzilla/show_bug.cgi?id=57284



 Comments   
Comment by Ed Burns [ 15/Dec/14 ]

If the Filter wants to go async, allowing them to do so would be
consistent with that design intent. In the absence of further data, let
me suggest some alternate text for section 6.2.3.

Proposed623> When operating in synchronous mode, a Filter and the target
Proposed623> servlet or resource at the end of the filter chain must
Proposed623> execute in the same invocation thread. When operating in
Proposed623> asynchronous mode, a Filter and the target servlet or
Proposed623> resource at the end of the filter chain must execute on the
Proposed623> invocation thread to which control is handed when the
Proposed623> asynchronous processing commences.

Comment by Ed Burns [ 15/Dec/14 ]

Further input from Mark Thomas.

Comment by gregwilkins [ 16/Dec/14 ]

I'm not sure this one is sufficiently agreed to be closed.

I'm not sure what the new text means when it says "on the invocation thread to which control is handed when the asynchronous processing commences". Asynchronous processing may not have 1 thread in control, it may have many threads in control.

Currently I am not convinced that we should allow arbitrary threads to call FilterChain.doFilter or RequestDispatcher.forward. I don't think it has been established why the current spec text is not good. I also think that any such change needs to be very carefully reviewed against issues such:
+ what should the getContextPath getSErvletPath methods return? what about the race with the exiting container thread?
+ what about calls to ServletRequestListeners are called and if ThreadLocals can be used.

Can we reopen this one and discuss more on the list?

Comment by Ed Burns [ 18/Dec/14 ]

svn commit -m "Revert change for SERVLET_SPEC-119" filters.fm
Sending filters.fm
Transmitting file data .
Committed revision 103.





[SERVLET_SPEC-127] Minor mistakes in the specification (Servlet 3.1 Final Release for Evaluation) Created: 21/Feb/15  Updated: 21/Feb/15

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

Type: Bug Priority: Minor
Reporter: Anthony Ve Assignee: Shing Wai Chan
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

section 2.3.3.1: "or methods such as doGet or doPost which are dispatched to the service method of the HttpServlet abstract class". This is exactly the other way around: the service method dispatches requests to the doXXX methods. From the javadoc http://docs.oracle.com/javaee/7/api/javax/servlet/http/HttpServlet.html: "There's almost no reason to override the service method. service handles standard HTTP requests by dispatching them to the handler methods for each HTTP request type (the doXXX methods listed above)."

section 3.7: "The container will subsequently invoke the onDataAvailable method if and only if isReady method on ServletInputStream, described below, returns false." should be "[...] returns true."

section 5.3: "The container will subsequently invoke the onWritePossible method if and only if isReady method on ServletOutputStream, described below, returns false." should be "[...] returns true."

section 5.7: "[...] then the request object remains valid until complete method on AsyncContext is called." should be "[...] then the response object [...]"

section 8.1.5: "type mime/multipart" should be "multipart/form-data"

section 11.3.3: "HttpSessionListener.destory" should be "HttpSessionListener.destroy"

chapter 13, introduction: "[...] setServletSecurity method of the ServletRegistration interface." should be "[...] setServletSecurity method of the ServletRegistration.Dynamic interface."

javadoc of ServletContainerInitializer http://docs.oracle.com/javaee/7/api/javax/servlet/ServletContainerInitializer.html: "annontation" should be "annotation"

javadoc of ServletSecurityElement http://docs.oracle.com/javaee/7/api/javax/servlet/ServletSecurityElement.html: "represntation" should be "representation"



 Comments   
Comment by Shing Wai Chan [ 21/Feb/15 ]

javadoc fix
Sending src/main/java/javax/servlet/ServletContainerInitializer.java
Sending src/main/java/javax/servlet/ServletSecurityElement.java
Transmitting file data ..
Committed revision 63779.





[SERVLET_SPEC-128] Clarify instantiation of a Servlet Created: 21/Feb/15  Updated: 21/Feb/15

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

Type: Bug Priority: Minor
Reporter: Anthony Ve Assignee: Shing Wai Chan
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Section 2.3.1 of the specification (Servlet 3.1 Final Release for Evaluation) merely says: "After loading the Servlet class, the container instantiates it for use."

I would like this to be clarified by including the constructor requirements & what happens if these requirements aren't met. For example:

After loading the Servlet class, the container instantiates it for use by invoking the no-args constructor (which may be private). If no such constructor is available, a ServletException is thrown.






[SERVLET_SPEC-129] Additional non-normative text regarding protected content and RequestDispatcher Created: 18/Mar/15  Updated: 18/Mar/15

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

Type: Bug Priority: Minor
Reporter: Ed Burns Assignee: Ed Burns
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

A common mistake when building on top of Servlet is to neglect the risk posed by allowing unsanitized strings to end up as the "path" argument to ServletRequest.getRequestDispatcher(). The risk is that unintended source code exposure could result. To mitigate this risk, I propose we add some non-normative text to the specification.

Add this text to the JavaDoc for ServletRequest.getRequestDispatcher():

Note that the contents of the entire web application, including implicitly protected areas as well as those protected by security constraints, are accessible via the RequestDispatcher. This should be contrasted with external requests to the web application, which are protected by security constraints and implicitly protected areas as specified in the section titled "Specifying Security Constraints" in the Security chapter and the section titled "Directory Structure" in the Web Applications chapter in the Servlet specification document.

Add similar text to the above in the JavaDoc for ServletContext.getResource().

Add similar text to the above in the JavaDoc for ServletContext.getResourceAsStream.

Add this text to the above mentioned Directory Structure section after the sentence beginning with "However, the contents of the WEB-INF directory are visible..."

Please see the javadoc of for method getRequestDispatcher() on ServletRequest, and for methods getResource() and getResourceAsStream() on ServletContext.






[SERVLET_SPEC-97] Host: header and IPv6 addresses Created: 25/Jul/14  Updated: 21/Aug/14

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

Type: Bug Priority: Trivial
Reporter: Ed Burns Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Duplicate
duplicates SERVLET_SPEC-93 Remove ambiguity in getServerName for... Resolved

 Description   

Clarify the handling of raw IPv6 addresses when they are sent as part of the URI authority and/or Host header.

GW> Currently the javadoc for getServerName says:

    /**
     * Returns the host name of the server to which the request was sent.
     * It is the value of the part before ":" in the <code>Host</code>
     * header value, if any, or the resolved server name, or the server IP
     * address.
     */

GW> That this is ambiguous, since for a Host header like [::1]:8080, both
GW> "[::1]" and "::1" satisfy an or clause in the javadoc (the part before the
GW> ":" and the server IP address).

GW> I'm not 100% sure what we should return, since including the [] makes
GW> constructing URIs easier (but we have getRequetURI for that), but the []
GW> are not part of the IP address and only part of the encoding of an IPv6
GW> address in a URI. Since the return is a hostname, then it should be able
GW> to be passed to methods that resolve host names, and they have no
GW> obligation to string []. So I probably lean towards stripping off the [].

GW> But whichever way we go, we should update the javadoc to make it clear what
GW> it is.



 Comments   
Comment by gregwilkins [ 30/Jul/14 ]

This duplicates #93, unless it is intended to make this a wider issue to check for other IPv6 host name issues?





[SERVLET_SPEC-95] Require that TLS is supported Created: 23/Jul/14  Updated: 21/Aug/14

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

Type: Improvement Priority: Trivial
Reporter: Ed Burns Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Section 1.2 states:

All servlet containers must support HTTP as a protocol for requests and responses, but additional request/response-based protocols such as HTTPS (HTTP over SSL) may be supported.

With the recent publishing of RFC 7258 / BCP 188 http://www.rfc-editor.org/rfc/rfc7258.txt TLS is encouraged to be the default for servers.

We will need to revisit the above text in light of BCP 188.






[SERVLET_SPEC-90] Investigate need for compliance with IETF PRECIS framework Created: 08/Jul/14  Updated: 21/Aug/14

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

Type: Improvement Priority: Trivial
Reporter: Ed Burns Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

According to Phil Hunt's blog entry, <https://blogs.oracle.com/fusionmiddleware/entry/standards_corner_ietf_revisits_http> there are a number of improvements in the recent HTTP 1.1 JSRs that should be investigated for their impact on Servlet.

This one involves how Unicode strings are processed before being passed to the consumers of the Servlet API.

See <http://tools.ietf.org/html/draft-ietf-precis-framework> for more information.






[SERVLET_SPEC-106] Mixing of query string and post body parameters Created: 19/Sep/14  Updated: 19/Sep/14

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

Type: Improvement Priority: Trivial
Reporter: lefloh Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

The specification defines in chapter 3.1:

Data from the query string and the post body are aggregated into the request parameter set.

This may lead to following problems:

1. The query string is usually used for non-hierarchical filtering of the addressed resources whereas the post body is used to send the data which should be stored or processed by the server. Both parameters at one time can be used by bulk operations like:

POST /articles?before=2014-01-01

archived=true

The only way to distinguish between both is manual parsing of getQueryString or the request body's input stream.

2. The encoding of the post body can be changed by setCharacterEncoding(String enc) whereas the encoding of the query string is usually ISO-8859-1 and can't be changed. So the request parameter set may be populated with parameters encoded with different charsets.

Would it be possible to add at a method which helps to distinguish between both?






[SERVLET_SPEC-101] What to do about userinfo in URLs? Created: 01/Aug/14  Updated: 21/Aug/14

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

Type: Improvement Priority: Trivial
Reporter: Ed Burns Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

RFC 7230 section 2.7.1 http uri scheme states:

Before making use of an "http" URI reference received from an untrusted source, a recipient SHOULD parse for userinfo and treat its presence as an error; it is likely being used to obscure the authority for the sake of phishing attacks.

Now, granted, it's only a SHOULD, but I wonder if we need to heed this in Servlet?






[SERVLET_SPEC-88] Who decides if the error message is safe to display? Created: 27/May/14  Updated: 27/May/14

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

Type: Bug Priority: Trivial
Reporter: Ed Burns Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Reported by Mark Thomas:

When an application calls HttpServletResponse.sendError(int, String) the
Javadoc states that:

The server defaults to creating the response to look like an
HTML-formatted server error page containing the specified message,
setting the content type to "text/html".

My question is a simple one.

If the message contains user provided data (for example it might say
"ABCDEFG is not a valid UK postcode) who is responsible for ensuring
that the message is safe to use in the error response? Is it the caller
or is it the component that generates the error response?

It is my belief that it is the component generating the error response
that is responsible. The caller does not know what format will be used
for the error response (HTML, XML, JSON, something else) and, therefore,
has no way of determining what is the appropriate escaping / encoding /
safety mechanism of choice to use. Therefore, it has to be the
responsibility of the component generating the response.

Do the other EG members agree and, if so, can we get the spec updated to
make that explicit?






[SERVLET_SPEC-121] Create components for this JIRA Created: 17/Dec/14  Updated: 17/Dec/14

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

Type: Task Priority: Trivial
Reporter: Ed Burns Assignee: Unassigned
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

The JIRA for Servlet Spec, https://java.net/jira/browse/SERVLET_SPEC/ has this unfortunate text on its admin page, "This project does not use any components." It would be really helpful to have some categories to help us work with issues.






Generated at Fri Mar 27 23:16:48 UTC 2015 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.