[SERVLET_SPEC-151] CLONE - Expose tls_unique as request attribute Created: 16/Dec/15  Updated: 16/Dec/15

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

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

Issue Links:
Cloners
clones SERVLET_SPEC-107 Expose tls_unique as request attribute Open

 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.






[SERVLET_SPEC-107] Expose tls_unique as request attribute Created: 25/Sep/14  Updated: 16/Dec/15

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

Issue Links:
Cloners
is cloned by SERVLET_SPEC-151 CLONE - Expose tls_unique as request ... Open

 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?

Comment by Ed Burns [ 23/Sep/15 ]

Mark, I'm not sure, but given that the feature was requested by Ron, I trust there is a valid usecase. I did some brief research and found <https://www.secure-resumption.com/>, where the following is stated:

For example the tls-unique channel binding refers to the first Finished message in the innermost handshake on the current connection, and hence by checking that this value matches on the client and server, they can presumably be assured that their communications are over the same connection.

Also, the RFC5929 Ron cites states

This definition of 'tls-unique' means that a channel's bindings
data may change over time, which in turn creates a synchronization
problem should the channel's bindings data change between the time
that the client initiates authentication with channel binding and
the time that the server begins to process the client's first
authentication message. If that happens, the authentication
attempt will fail spuriously.

So, I think we should add a row in the table in section 3.9 to honor Ron's request.

Comment by Ed Burns [ 23/Sep/15 ]

More text from the RFC.

7. Required Application Programming Interfaces

TLS implementations supporting the use of 'tls-unique' and/or 'tls- unique-for-telnet' channel binding types MUST provide application programming interfaces by which applications (clients and servers both) may obtain the channel bindings for a TLS connection. Such interfaces may be expressed in terms of extracting the channel bindings data for a given connection and channel binding type. Alternatively, the implementor may provide interfaces by which to obtain the initial client Finished message, the initial server Finished message, and/or the server certificate (in a form that matches the description of the 'tls-server-end-point' channel binding type). In the latter case, the application has to have knowledge of the channel binding type descriptions from this document. This document takes no position on which form these application programming interfaces must take.

TLS implementations supporting TLS renegotiation SHOULD provide APIs that allow applications to control when renegotiation can take place. For example, a TLS client implementation may provide a "callback" interface to indicate that the server requested renegotiation, but may not start renegotiation until the application calls a function to indicate that now is a good time to renegotiate.





[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-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-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-26] Valid response header names and values Created: 07/Oct/11  Updated: 25/Sep/15

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

Comment by markt_asf [ 24/Sep/15 ]

My own view is that invalid headers names and/or values should be rejected with an IllegalArgumentException.

Comment by gregwilkins [ 25/Sep/15 ]

I'm fine with ISE being thrown, but I think the spec cannot define what is or is not a valid header name. That will be determined by the underlying transport and level of RFC implementation. So I think these methods MAY throw rather than MUST throw.

Comment by Shing Wai Chan [ 25/Sep/15 ]

I agree that Servlet spec cannot define what valid header names are as they defined by RFCs, etc. And there may be new RFCs in the future. So, the method may throw IllegalArgumentException seems to be better.





[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-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-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-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-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-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-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-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-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-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: 1
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-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-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-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-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-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-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-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-133] User listener for async dispatch Created: 24/Jul/15  Updated: 24/Jul/15

Status: Open
Project: servlet-spec
Component/s: None
Affects Version/s: 4.0
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   

Currently the context listeners can be used to bracket threads that are dispatched to the servlet container for normal request processing. However there is no mechanism to allow user code to bracket threads that are used for asynchronous callbacks.

There is the call AsyncContext.start(Runnable) that allows an application to anoint a thread with any container provided context, but it does not support any application extension.

A AsyncDispatchListener that was called before and after each AsyncContext.start and for every async callback (eg onDataAvailable) then application code could do its own anointing (eg setting/clearing thread locals).






[SERVLET_SPEC-131] Advanced form based authentication Created: 24/Apr/15  Updated: 05/Aug/15

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

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


 Description   

We use form based authentication with a full-fledged JSF ajaxified page. Notably it relies on HttpServletRequest#login instead of j_security_check. This allows to us to easily implement the login page with same look-and-feel as the other pages of our application: error handling, notifications, visual styling; and no "j_security_check in browser address bar after failed login" problem.
We only wish this was supported better at the spec level. For example, the original request preservation feature creates problems: it can't possibly work here because of JSF's javax.faces.ViewState parameter - if it comes from a dead view in a dead session, then it just won't work. We had to work around it by cleaning the container stored request.



 Comments   
Comment by VsevolodGolovanov [ 24/Apr/15 ]

The original request preservation creates problems in case of JSF POSTs mainly. GETs could work, but we don't use that too, since window.reload fits better in our case. Maybe at least make this preservation behavior configurable.

Comment by arjan tijms [ 03/Aug/15 ]

There's absolutely room for improvement here indeed. The existing FORM is not ideal for usage with JSF.

Via JASPIC you can already add custom authentication mechanisms yourself, and I've been testing with a custom mechanism that's arguably better suited for working with JSF. See OmniServerAuthModule.java

View state is a difficult issue. If state is stored on the client, or if state isn't there at all (JSF's stateless mode) then preserving the POST data always works for full page requests. However, AJAX is still problematic, since after a form page is displayed the user should not be redirected to the original AJAX request. Instead, the JSF client side AJAX handler (e.g. the javascript code that did the original request) should retry the request.

Since I'm in both the Security EG and JSF EG I did a fair amount of research to come up with a proposal to solve this, but as of yet did not succeed.

Comment by VsevolodGolovanov [ 05/Aug/15 ]

I've tried to lay out specific problems.

  1. Request saving.
  2. I've defined my login page as a form-login-page in the web.xml, but...
    1. The specification is very strict that the login form must contain j_username and j_password fields, and the action must be j_security_check. I violate these requirements.
    2. I have to specify form-error-page too, even though it is not used.
  3. Not using j_security_check means the login page gets served automatically by the container, but for the login page POSTs I had to specify appropriate mappings and constraints myself. That's seems inconsistent. Maybe allow specifying the action used for logging in in web.xml, to allow the container to handle it appropriately as well?

arjan tijms, I don't understand, what problem does OmniServerAuthModule solve?

Comment by arjan tijms [ 05/Aug/15 ]

>The specification is very strict that the login form must contain j_username and j_password fields, and the action must be j_security_check. violate these requirements.

It's not so much violating really. The requirements are what the build in authentication mechanism FORM must support, not what your application must use.

j_security_check is just the path this build-in code "listens" to. Your application does not HAVE to use this, as HttpServletRequest#authenticate and HttpServletRequest#login are still valid methods for your application to use according to the spec.

>I don't understand, what problem does OmniServerAuthModule solve?

It's an authentication mechanism essentially on the same level as the build-in FORM one (all JASPIC SAMs are essentially on that level).

It does a redirect to a login page when a protected resource is accessed, but it does not have the j_username, j_password and j_security_check requirements which all are not ideal for JSF as you mentioned.

The thing is that typically for JSF you'd want the input to be validated on the server by your own code and then validation messages displayed on the same page in case of problems. OmniServerAuthModule essentially only does the redirect to a login page when a protected resource is accessed, and otherwise just passes the credentials to the configured identity store.





[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-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-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-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-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-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-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-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-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-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-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-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-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-73] Provide a way to find out mapping type used for selecting Servlet Created: 22/May/13  Updated: 11/Sep/15

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: 0 minutes
Time Spent: 2 hours, 56 minutes
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.

Comment by Ed Burns [ 11/Sep/15 ]

See discussion at <https://java.net/projects/servlet-spec/lists/jsr369-experts/archive/2015-09/message/21>.





[SERVLET_SPEC-143] HttpServlet.service(ServletRequest,ServletResponse) missing throws text Created: 28/Sep/15  Updated: 28/Sep/15

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

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


 Description   

HttpServlet.service(ServletRequest,ServletResponse) has this @throws clause:

@exception ServletException if the HTTP request cannot be handled

But the RI also throws ServletRequestion if either incoming parameter is not an instanceof their Http counterpart.

I think this should be explicitly stated.



 Comments   
Comment by Ed Burns [ 28/Sep/15 ]

M src/main/java/javax/servlet/http/HttpServlet.java

+ * @throws ServletException if the HTTP request cannot
+ * be handled or if either parameter is not
+ * an instance of its respective

{@link HttpServletRequest}

+ * or

{@link HttpServletResponse}

counterparts.

  • @see javax.servlet.Servlet#service
    */
  • Added text to the @throws ServletException of
    HttpServlet.service(HttpServletRequest, HttpServletResponse).
    Sending src/main/java/javax/servlet/http/HttpServlet.java
    Transmitting file data .
    Committed revision 64145.




[SERVLET_SPEC-147] Allow programmatic read access to the configuration Created: 09/Oct/15  Updated: 09/Oct/15

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

Type: New Feature 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   

Some web libraries are interested in the web app configs and parse web.xml/web-fragment.xml themselves. Examples.

  • Mojarra's com.sun.faces.config.ConfigureListener.WebXmlProcessor: checks for the FacesServlet, error-page and 'distributable' definitions.
  • OmniFaces' org.omnifaces.config.WebXml: welcome files, error pages, form login page, form error page, security constraints, session timeout.
  • PrimeFaces' org.primefaces.config.ConfigContainer: error pages.

There are proposed additional programmatic configuration APIs: SERVLET_SPEC-48, SERVLET_SPEC-50, SERVLET_SPEC-70. Their implementation would mean that those interested web libraries won't be able to see the programmatically configured things. Thus the need for a corresponding configuration reading API.



 Comments   
Comment by VsevolodGolovanov [ 09/Oct/15 ]

Maybe even expose the method to lookup error pages by exceptions? Both PF and OF reimplement it.
The lookup algorithm is well defined, but both of those libraries messed it up initially nonetheless.





[SERVLET_SPEC-134] Provide API supporting HTTP/2 Server Push Created: 14/Aug/15  Updated: 30/Oct/15

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

Type: Bug Priority: Major
Reporter: Ed Burns Assignee: Ed Burns
Resolution: Unresolved Votes: 0
Labels: None
Remaining Estimate: 0 minutes
Time Spent: 5 hours, 51 minutes
Original Estimate: Not Specified


 Description   

The most visible user facing feature of HTTP/2 is Server Push. This issue tracks introducing Server Push to the Servlet API.



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

Doing the work in this branch <https://svn.java.net/svn/glassfish~svn/branches/SERVLET_SPEC-134>.





[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: 1
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-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-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: 1
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-146] Add ability to specify URL encoding Created: 04/Oct/15  Updated: 04/Oct/15

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

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


 Description   

Implementations use encodings for three different things:

  1. the response body
  2. the request body
  3. the request URL

The specification provides API methods to configure the first two but no way to configure the last one (encoding of the request URL). This makes it impossible to create a portable application that uses non-ASCII URLs (or GET forms) and forces users to rely proprietary sever configuration.

For additional information check out this thread:
https://java.net/projects/servlet-spec/lists/users/archive/2015-08/message/41

Optionally a fix can include one central place to configure all three encodings but this is not required.






[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: 17
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-152] Clarify ServletContextListener.contextDestroyed() call requirements on application startup failure Created: 09/Mar/16  Updated: 10/Mar/16

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

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


 Description   

When migrating an application from Jboss EAP 6 (Tomcat based) to WildFly, I've encountered a change of behavior with ServletContextListeners that are not cleaned-up properly anymore (contextDestroyed() called) if an exception is thrown during application startup.

Steps to reproduce:
1 - Register two listeners (in web.xml)
2 - First one initializes correctly (contextInitialized())
3 - Second one throws a RuntimeException (contextInitialized())
4 - (On Jboss EAP 6): contextDestroyed() was called on both listeners.
5 - Failed application was undeployed successfully.

Behavior on different servlet implementations:

  • Tomcat (up to 9): contextDestroyed() is called on all listeners (including the one that failed to initialize)
  • Jboss EAP 6: Same as Tomcat (expected)
  • WildFly 8-10: contextDestroyed() not called on any listener.
  • Glassfish 4: contextDestroyed() not called on any listener

The 2.5 and 3.0+ servlet-api documents are not clear on the expected behavior.

  • 2.5, SRV.9.12 Web Application Deployment
    • Explains that contextInitialized() must be called for all instanciated listeners. No clear behavior for contextDestroyed().
  • 3.0+, 8.2.3 Assembling the descriptor from web.xml, webfragment.xml
    and annotations.
    • Clarify the order of initialization and cleanup of listeners (based on order in web.xml).

In my opinion, the behavior I would expect is the following:

  • contextDestroyed() SHOULD be called for every listeners for which a successful initialization occured. This way, proper cleanup would be ensured.
  • contextDestroyed() SHOULD NOT be called for listeners that failed to initialized. Behaviour would be consistent with the "2.3.2.1 Error Conditions on Initialization" section on servlet initialization/cleanup.


 Comments   
Comment by glavoie84 [ 09/Mar/16 ]

Here's a small code sample to reproduce.

import javax.servlet.ServletContextEvent;
import javax.servlet.ServletContextListener;

public class Listener1 implements ServletContextListener {
    @Override
    public void contextInitialized(ServletContextEvent servletContextEvent) {
        System.out.println("Listener1 initialized.");
    }

    @Override
    public void contextDestroyed(ServletContextEvent servletContextEvent) {
        System.out.println("Listener1 destroyed.");
    }
}
import javax.servlet.ServletContextEvent;
import javax.servlet.ServletContextListener;

public class Listener2 implements ServletContextListener {
    @Override
    public void contextInitialized(ServletContextEvent servletContextEvent) {
        System.out.println("Listener2 initialized.");
        throw new RuntimeException("Listener2 broken");
    }

    @Override
    public void contextDestroyed(ServletContextEvent servletContextEvent) {
        System.out.println("Listener2 destroyed.");
    }
}
<?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns="http://xmlns.jcp.org/xml/ns/javaee"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://xmlns.jcp.org/xml/ns/javaee http://xmlns.jcp.org/xml/ns/javaee/web-app_3_1.xsd"
         version="3.1">

    <listener>
        <listener-class>Listener1</listener-class>
    </listener>

    <listener>
        <listener-class>Listener2</listener-class>
    </listener>
</web-app>

Output on Tomcat/Jboss EAP 6:

Listener1 initialized.
Listener2 initialized.
... Stacktrace for RuntimeException("Listener2 broken")
Listener2 destroyed.
Listener1 destroyed.
... Container deployment error message.

Output on WildFly/Glassfish:

Listener1 initialized.
Listener2 initialized.
... Stacktrace for RuntimeException("Listener2 broken")
... Container deployment error message.
Comment by gregwilkins [ 10/Mar/16 ]

For completeness Jetty produces the following results:

Listener1 initialized.
Listener2 initialized.
java.lang.RuntimeException: Listener2 broken
Listener2 destroyed.
Listener1 destroyed.

For further investigation, I added a third listener to see if it's initialised method get's called even after listener2 throws. Jetty's results are:

Listener1 initialized.
Listener2 initialized.
java.lang.RuntimeException: Listener2 broken
Listener3 destroyed.
Listener2 destroyed.
Listener1 destroyed.

Which is probably not good. Either Listener3 should be initialised or it's destroy should not be called.

I believe the OP is suggesting the results should be:

Listener1 initialized.
Listener2 initialized.
java.lang.RuntimeException: Listener2 broken
Listener1 destroyed.

This would be good to have clarified

Comment by glavoie84 [ 10/Mar/16 ]

Greg,
thanks for adding Jetty's result. I also believe Jetty's result is not good with a 3rd listener. Your last sample output is exactly what I am suggesting.

Thanks!

Comment by gregwilkins [ 10/Mar/16 ]

So what if Listener2 throws in destroy rather than initialized? Should Listener1 destroy still be called?

Comment by glavoie84 [ 10/Mar/16 ]

I think that Listener1 destroy() should still be called as it was previously fully initialized, thus in a proper state for being destroyed properly.

Now given that we have the proper tools to do a proper cleanup, I think the developer has some responsibility to do some error management when required.

For example, let say Listener2 does a multi-step initialization that could possibly leak resources, but one of the step fails with an unmanageable error. It should be up to Listener2 to attempt to do as much cleanup as possible, still within the "contextInitialized()" call, before rethrowing the error. At this point the startup of the application would still fail, but previously initialized ServletContextListeners would still have a chance to do their cleanup. And other applications living on the container will have a chance to survive without a restart of the JVM.

Same if Listener2 fails during the contextDestroyed() call. We can't tell the outcome for all error scenarios, but other listeners would have the chance to do a proper cleanup and it becomes the developer's responsibility to tell if the error would require a container restart or not.

Comment by gregwilkins [ 10/Mar/16 ]

So this is a jetty unit test that I believe describes what we think should happen:

        ServletContextHandler context = new ServletContextHandler();

        final List<String> history=new ArrayList<>();

        context.addEventListener(new ServletContextListener()
        {
            @Override
            public void contextInitialized(ServletContextEvent servletContextEvent)
            {
                history.add("I0");
            }

            @Override
            public void contextDestroyed(ServletContextEvent servletContextEvent)
            {
                history.add("D0");
            }
        });
        context.addEventListener(new ServletContextListener()
        {
            @Override
            public void contextInitialized(ServletContextEvent servletContextEvent)
            {
                history.add("I1");
            }

            @Override
            public void contextDestroyed(ServletContextEvent servletContextEvent)
            {
                history.add("D1");
                throw new RuntimeException("Listener1 destroy broken");
            }
        });
        context.addEventListener(new ServletContextListener()
        {
            @Override
            public void contextInitialized(ServletContextEvent servletContextEvent)
            {
                history.add("I2");
                throw new RuntimeException("Listener2 init broken");
            }

            @Override
            public void contextDestroyed(ServletContextEvent servletContextEvent)
            {
                history.add("D2");
            }
        });
        context.addEventListener(new ServletContextListener()
        {
            @Override
            public void contextInitialized(ServletContextEvent servletContextEvent)
            {
                history.add("I3");
            }

            @Override
            public void contextDestroyed(ServletContextEvent servletContextEvent)
            {
                history.add("D3");
            }
        });
        
        try
        {
            context.start();
        }
        catch(Exception e)
        {
            history.add(e.getMessage());
        }
        finally
        {
            try
            {
                context.stop();
            }
            catch(Exception e)
            {
                while(e.getCause() instanceof Exception)
                    e=(Exception)e.getCause();
                history.add(e.getMessage());
            }
            finally
            {
            }
        }
         
        Assert.assertThat(history,Matchers.contains("I0","I1","I2","Listener2 init broken","D1","D0","Listener1 destroy broken"));

Comment by glavoie84 [ 10/Mar/16 ]

I have a few comments on the unit test:

  • The context.start() wrapping looks fine as the process should stop with the first exception.
  • Not sure about the context.stop() implementation, but the wrapping suggests a single exception will be thrown, which would be the "Listener1 destroy broken" exception because it is added to history.
    • I see two options:
      • contextDestroyed() exceptions could be accumulated and returned by context.stop()
      • contextDestroyed() exceptions could be printed immediately as they occur and context.stop() would throw a more general exception to tell one or more issues occurred during the process.
  • Matchers.contains() tells me that the order is not important in the history List, but it is (per servlet 3.0 spec).
    • Asserting the number of elements in the history List would also be a good idea.
    • With the two suggested error management scenarios, the "Listener1 destroy broken" entry would either stay at the end or appear right after "D1".
Comment by gregwilkins [ 10/Mar/16 ]

I think the throwing of the exception is a little bit container specific. In jetty's case if there is only 1 exception it is thrown. If multiple exceptions are thrown then a MultiException is thrown with the first of the real exceptions as the cause and the rest are added as suppressed exceptions. In jetty behaviour is also related to how it was started (ie should the context stay up in unavailable state or should the whole container fail to start).

The important thing here is exactly which destroys get called?

Comment by glavoie84 [ 10/Mar/16 ]

I agree with you that the exception management is container specific and I think that what you explain is perfectly fine. I just wasn't sure about how you wanted to test it with your unit test.

Yes, the important thing is which destroys get called.





[SERVLET_SPEC-153] Specify allowable characters for context-root Created: 25/Mar/16  Updated: 25/Mar/16

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

Type: Bug Priority: Major
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   
>>>>> On Thu, 17 Mar 2016 19:10:56 +0000 (UTC), PB said:

PB> Dear EG Members,
PB> I'd like to get clarification in regards to the following. I am quoting
PB> from EE 5.0 (see link below), section 8.3.1, paragraph 3c. This
PB> language still exists in EE 7 and dates back to at least EE 1.3:

PB> The Deployer must... "Assign a context root for each web module
PB> included in the Java EE application. The context root is a relative
PB> name in the web namespace for the application. Each web module must be
PB> given a distinct and non-overlapping name for its context root."

PB> This scenario I have today:
PB> /context/something <-- context is /context
PB> /context/something/somethingelse <-- context is /context/something

PB> Please advise on these points:

PB> a) The specification puts no limitations on the context root character
PB> set (so it can include a slash). With that said, would you consider
PB> these "overlapping" contexts as the specification defines it? 

The specification should be explicit in which characters are allowed in the context-root.






[SERVLET_SPEC-154] Consider requiring context-roots to be unique server-wide Created: 25/Mar/16  Updated: 29/Mar/16

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   
>>>>> On Thu, 17 Mar 2016 19:10:56 +0000 (UTC), PB said:

PB> I'd like to get clarification in regards to the following. I am quoting
PB> from EE 5.0 (see link below), section 8.3.1, paragraph 3c. This
PB> language still exists in EE 7 and dates back to at least EE 1.3:

PB> The Deployer must... "Assign a context root for each web module
PB> included in the Java EE application. The context root is a relative
PB> name in the web namespace for the application. Each web module must be
PB> given a distinct and non-overlapping name for its context root."

PB> This scenario I have today:
PB> /context/something <-- context is /context
PB> /context/something/somethingelse <-- context is /context/something

PB> Please advise on these points:

PB> b) What does the language "web namespace for the application" really
PB> mean? If I take "application" to mean EAR, it sounds like this
PB> restriction is only within an EAR; yet I am puzzled why the restriction
PB> isn't meant for the entire application server.

>>>>> On Mon, 21 Mar 2016 10:59:23 -0700, B said:

B>     b) Yes, this restriction is only within the EAR.  The reference
B>        implementation (GlassFish) imposes this for the entire server.
B>        The Servlet spec should probably require that.



 Comments   
Comment by Ed Burns [ 25/Mar/16 ]

>>>>> On Mon, 21 Mar 2016 10:59:23 -0700, B said:

B> d) The rule only applies for multiple web modules in an EAR file.
B> As in (b), it probably should apply to the entire server.

Comment by markt_asf [ 26/Mar/16 ]

The non-overlapping roots in a EAR requirement doesn't make much sense to me. It means that the developer has to choose between one WAR with a root of "/" and multiple WARs none of which can use "/". The Servlet spec has a very sensible, unambiguous matching rule "match URL against the longest matching context path first". I don't see why the that can't work in an EAR as well.

I would be very strongly -1 on the Servlet spec not allowing overlapping context roots. It would break a significant proportion of existing deployments.

Generally, context paths do have to be unique within a virtual host (which implies within an EAR too). This is implied at the moment since, if context paths are not unique, the app server has no way to select the correct context. However, we need to be careful how the requirement is worded since Tomcat (and at least one full JavaEE implementation I am aware of) has a parallel deployment feature that allows multiple versions of an application to exist in parallel. Those WARs all have the same context path. We don't want the Servlet spec blocking such a useful feature.

Something like:
"Within a virtual hosts, web applications must be assigned unique context paths unless the implementation uses implementation specific configuration (e.g. an application version attribute) to differentiate between them."

Comment by stuartdouglas [ 26/Mar/16 ]

I also really don't think we need this restriction, and I think it should probably be removed from EAR files as well. As far as I can tell allowing overlapping roots causes no problems, disabling would break existing deployments and removes flexibility for no gain that I can see.

I also don't think we need to explicitly restrict to unique context paths, IMHO the container should be free to decide what makes sense and can be supported, and what should be rejected.

Comment by pbenedict [ 26/Mar/16 ]

The reason I started this discussion wasn't for academic exercise. I came across this problem which caused 503 errors because proxies and application servers don't work well with overlapping contexts. Most people who run Apache in front with mod_proxy/ajp are going to have problems. It's not clear why overlapping contexts should be supported besides "that's the way things have been" ? It does violate the principle of least surprise and integration code is evidently surprised by it too.

Comment by stuartdouglas [ 26/Mar/16 ]

We should not be changing the spec because of a bug in an AJP implementation. Their is nothing inherent in the AJP protocol that would prevent this from working.

The main reason why this should be supported is because there is no reason not to. The fact that the container will match against the longest path means there is no ambiguity. If we enforced this it would also mean that if you deploy something at the context root you cannot have any other deployments on this server.

Other than the context root case there are also lots of other cases where overlapping context roots make sense, e.g. a separate admin war. If you want your main app at /app and your admin war at /app/admin this would prevent that, for no good reason.

Comment by pbenedict [ 26/Mar/16 ]

I am not asserting there is a bug in AJP. I used that as an example because that's how I found the problem. My Apache is acting as a proxy and all its configuration is generated in real-time through management controls. Evidently the context order matters, but who knew?

I also can't speak to any other proxy server. So while you are saying the servlet specification is okay, I think it means that proxies need to be really clever. Someone who is proxying a Java app server needs to be aware of context matching rules to forward the request along correctly. Is that really the intention?

Comment by markt_asf [ 27/Mar/16 ]

If you are going to try proxying overlapping URL paths in different ways then you are going to need to be very careful with your proxy configuration regardless of whether the backend service is a Servlet container, a full JavaEE server, a PHP app, another web server or something else. If you are using httpd as the reverse proxy, the documentation for the ProxyPass directive is explicit about the requirement for correct ordering of the ProxyPass directives in the case of overlapping paths. The proxy configuration complexity is not the result of the Servlet specification and placing unnecessary limits in the Servlet spec is not the way to fix this.

Consider the following. If you have Servlet Container A servering context /foo and Servlet Container B serving context /foo/bar both behind the same reverse proxy then the no overlapping contexts rule doesn't help since each Servlet container - which has no knowledge of the other container - only has a single context. It gets even more tricky if you opt to change the context path in the proxy (not something I recommend since you have to very very, very careful not to break stuff but I still see folks try to do this all the time). You could have a single Servlet container with /foo and /bar but a proxy configured as /foo -> /foo and /foo/bar to /bar. Again, very tricky to get the config right in the proxy but as far as the Servlet container is concerned - no overlapping context paths.

I'll note at this point in that in the 10+ years I have been answering reverse proxy configuration questions on the Tomcat users list and for customers I don't ever recall this problem coming up. While it is possible I may have forgotten a question or two, the assertion that "Most people who run Apache in front with mod_proxy/ajp are going to have problems." is simply not correct.

In short - this is a proxy configuration problem and nothing to do with the Servlet spec. It is also independent of the protocol used between the reverse proxy and the back-end service. You'll have exactly the same issues with AJP, HTTP, HTTP/2 or any other protocol you care to choose.

Comment by pbenedict [ 27/Mar/16 ]

I appreciate everyone's comments. Personally, I don't care if "distinct and overlapping" contexts exist or not. I am not a fan of them and the behavior caught me by surprise, but evidently the discussion is in strong favor for them. I'd rather have clarity regardless what is decided.

Also, correct me if wrong, but I find this to be a very implied feature of the Servlet specification. I haven't yet found wording that explicitly calls it out. I skimmed the 3.1 specification again and may have missed it. Please advise. Section 3.5 calls out how the context matches the servlet, but where does the container match the context? Mark, I searched what you quoted ("match URL against the longest matching context path first") but cannot find it. Are you by chancing quoting the EE spec?

Anyway, these are my recommendations:

1) EE spec needs to be updated to remove the "distinct and overlapping" restriction

2) In coordination with SERVLET_SPEC-153, call out "/" is allowed inside the context name and thus contexts may overlap

3) Update section 4.1. The example demonstrates with /catalog and says "All requests that begin with the /catalog request path, known as the context path, are routed to the Web application associated with the ServletContext" but that is true if there is no overlapping context with /catalog.

Comment by markt_asf [ 27/Mar/16 ]

I think the reason that overalpping context paths are not explicitly called out as a feature is because it makes little sense not to support them. Without overlapping contexts you can't have more than one web application and serve a request for http://host:port/. The entire servlet spec is written on the basis that context paths can and will overlap.

Regarding the longest context path matches rule, see Servlet 3.1, section 12.1, first paragraph, second sentence. It wasn't a direct quote so you'd have to have searched for "longest" to find it.

Another place that implies overlapping context paths is section 3.5 that discusses the root context (context path "") and other context paths.

Section 4.1 looks like a reasonable simplification of the general case given the context.

I see some merit in pulling together the information that is currently in the spec regarding the definition of context path into a single location but I don't think that any further definition is required. It follows the rules for URLs (defined elsewhere) with the restrictions specified by section 3.5 and the additional information provided in the Javadoc (which forms part of the spec) for getContextPath().

Comment by pbenedict [ 27/Mar/16 ]

Thanks Mark. Perhaps we can get clarification from Bill Shannon on his original answer then. He said "the reference implementation (GlassFish) imposes this for the entire server. The Servlet spec should probably require that." I'd like to know more about how GlassFish is handling overlapping contexts. Most of your latest points are regarding the root context. Does GlassFish provide an exception for that, or is that treated absolutely too?

Comment by pbenedict [ 28/Mar/16 ]

I left myself a note to bring up this excerpt from Section 10.5. Please advise on how it relates to overlapping contexts.

Since the context path of an application determines the URL namespace of the contents of the
Web application, Web containers must reject Web applications defining a context
path that could cause potential conflicts in this URL namespace. This may occur, for
example, by attempting to deploy a second Web application with the same context
path. Since requests are matched to resources in a case-sensitive manner, this
determination of potential conflict must be performed in a case-sensitive manner as
well.

The most pertinent wording is "Web containers must reject Web applications defining a context path that could cause potential conflicts in this URL namespace." While it then goes on to list duplicate context roots as a conflict (obvious), are there any other kind of conflicts? I would categorize "overlapping contexts" as a type of conflict since one squats in the URL namespace of another.

Comment by markt_asf [ 29/Mar/16 ]

Over-lapping contexts are not conflicting since the "match the longest context path first" rule removes the ambiguity and every Servlet container should behave the same way.

Apart from duplicate context paths (assuming the same virtual host and no container specific feature - e.g. versioning - to distinguish between them) I can't think of any other way that a conflict could occur.

The wording of 10.5 is interesting. It reads to me as if:

  • the intent was prevent conflicting deployments while allowing containers some flexibility
  • duplicate context paths was viewed as the most likely (only?) cause of conflicts
  • the intent was to include any other cause of conflict if they emerged in the future
  • allow duplicate context paths ("may occur") if there is some other factor that allows the container to distinguish between them
Comment by pbenedict [ 29/Mar/16 ]

Mark, I must respectfully disagree with you that overlapping contexts are not a type of conflict. I say that in regard to Section 10.5, which states a context is a URL namespace and conflicts with that namespace should be rejected. If an application register context /foo and and another registers /foo/bar, the latter squats the URL namespace of the former. Under the wording of Section 10.5, the first application owns /foo and everything under it – because it's a namespace. These two example contexts are interfering namespaces.

If overlapping contexts are meant to exist, then the wording of this section should be tossed.





[SERVLET_SPEC-155] Clarification on getDefaultSessionTrackingModes and getEffectiveSessionTrackingModes Created: 31/Mar/16  Updated: 02/Apr/16

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 Servlet 3.1 javadoc of ServletContext#getDefaultSessionTrackingModes, we have
"Gets the session tracking modes that are supported by default for this ServletContext."

The description indicates that the above API returns a list of supported session tracking modes.

However, in javadoc of #getEffectiveSessionTrackingModes(), we have
"By default, the session tracking modes returned by getDefaultSessionTrackingModes are in effect."

This will be an issue when the server supports COOKIE, URL and SSL as SSL cannot be effective with COOKIE and URL at the same time. (See javadoc of #setSessionTrackingModes.)



 Comments   
Comment by Shing Wai Chan [ 31/Mar/16 ]

In this case, I proposed to remove the third line of description in #getEffectiveSessionTrackingModes(). That is, removing the following:
"By default, the session tracking modes returned by getDefaultSessionTrackingModes are in effect."

Comment by markt_asf [ 02/Apr/16 ]

OK, but if the web application does not explicitly request a tracking mode what should the effective tracking modes be? I suggest default less SSL unless SSL is the only one in which case use SSL.





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

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



 Comments   
Comment by stuartdouglas [ 07/Apr/16 ]

-1 to this, we already support multipart requests via the Part interface.

The numeric return values are IMHO also unessesary, the same thing can be accomplished by a one line call to a parse method for the relevant numeric type. I see no reason to clutter up our interfaces to save what basically amounts to a single method call.

Comment by markt_asf [ 07/Apr/16 ]

Agreed, I see no need for this API clutter.





[SERVLET_SPEC-132] WebSocket and Servlet mappings clarification Created: 07/May/15  Updated: 07/Apr/16

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

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


 Description   

Websocket endpoints declare mappings similar to a servlet mapping but the specification does not provide any guidance on how to handle these mapping when they exist in the same application. Should an endpoint mapping be considered as just another servlet mapping or something different based on the presence of an upgrade header?

For example, could a servlet and endpoint use the same mapping? The servlet is called in the absence of an upgrade header and the endpoint with the presence of an upgrade header? Or should this be a mapping clash?

For example, if an endpoint mapping uses a wildcard /home/* and a request is received for /home/index.html should the request be passed to the endpoint or the static file processor? Once again, could the destination be determined by the presence of an upgrade header?



 Comments   
Comment by Pavel Bucek [ 12/May/15 ]

Why do you think this should be filed against Servlet?

From my point of view, if WebSocket spec defines something without all required details, we should make the adjustment in WebSocket spec, not in Servlet; Servlet spec does not need to know about WebSocket and its mapping and WebSocket spec should do better job in terms of the description of Servlet integration in that regard.

Comment by mmulholl [ 12/May/15 ]

Well, we have section 12 in the spec which this question relates to. If we just implement what is in section 12 it means a websocket endpoint is just another servlet mapping, customers have to be aware of clashes between endpoint mappings and servlet mappings and extension processing, which is fine if that is the answer. However, if the servlet implementation should be sensitive to the upgrade header when mapping requests that would need an update to the servlet spec.

Comment by stuartdouglas [ 12/May/15 ]

The way we (Undertow) handle this is to install the websocket handler as a filter at the end of the filter chain. This gives user filters a chance to operate on the request before it is upgraded, and if there are no upgrade headers present then the request will be handled by any mapped servlet as normal.

Comment by Pavel Bucek [ 13/May/15 ]

@mmulholl: why would server need to recognise upgrade header? It is just HTTP request as others. Also I don't agree that single endpoint is another servlet mapping - @ServerEndpoint does not say anything about SERVLET mapping, it is just an alignment WITHIN WebSocket application, which has different rules and WebSocket spec deals with them (see JSR 356, chapter 3.1.1).

@stuartdouglas: we (Tyrus) do the same thing. And as you, we did not encounter any major issues with it (yet..), so it seem to be viable solution.

The issue might be more about how is the websocket application intergrated (mapped) into servlet mapping and that does not seem to be correctly defined. What is usually done is that the container registers single ServletFilter, which handles all upgrade requests (mapping "/*") and it is at the end of the filter chain. We might need to put something like this into WebSocket spec, but Servlet does not need to know about it.

Comment by stuartdouglas [ 07/Apr/16 ]

I think this can be closed, IMHO any clarification here belongs in the websocket spec.

Comment by markt_asf [ 07/Apr/16 ]

+1 to closing this.





[SERVLET_SPEC-139] Add int getStreamId() to HttpServletRequest and HttpServletResponse. Created: 16/Sep/15  Updated: 07/Apr/16

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   

Add new method

public int getStreamId()

to HttpServletRequest and HttpServletResponse.



 Comments   
Comment by gregwilkins [ 16/Sep/15 ]

Perhaps this could be abstracted a bit more - getTransportId? so for HTTP/1 it could give some identifier that represents the TCP/IP connection?

Note also that in HTTP2 streams can exist without requests (eg carrying websocket or just created empty as a priority marker).

Comment by Shing Wai Chan [ 18/Sep/15 ]

What is the use cases for this? Do application needs to know the streamId?

Comment by Ed Burns [ 18/Sep/15 ]

It's certainly less necessary now that SERVLET_SPEC-138 has been closed.

Comment by gregwilkins [ 20/Sep/15 ]

I do think it can be useful to expose some kind of connection/transport ID.
This is already available to some extend for https as the SSL session ID can be used to determine if two requests came from the same connection or not. Thus this could be generalized to a getConnectionId which would return something unique for the transport used.

I do know that a few webapps do care about this and have used container specific methods to determine this information, however I don't think they are common enough use-cases to insist something like this must be in the spec.

Comment by stuartdouglas [ 07/Apr/16 ]

I don't think getStreamId() is useful, it does not actually tell you anything without also some way of identifying the connection that the stream is associated with. getConnectionId() could be more useful, but I am worried about the potential for misuse if the server is behind a proxy.

I can see developers making assumptions about how getConnectionId() works based on their development machine, that no longer hold true once the app is in production due to the presence of a reverse proxy.

Comment by markt_asf [ 07/Apr/16 ]

Absent a valid use case, I'm fine with not supporting either method in the spec API.





[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: 1
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-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: 4
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-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: 1
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-157] Add a way to dinamycally register new Security Constraints Created: 02/Jul/16  Updated: 03/Jul/16

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

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


 Description   

Servlets and Filters can be programmatically added and modified via ServletContextListener and ServletContainerInitializer. However AFAIK, there's no way to dynamically create a new Security Constraint based on a custom url, although you can add constraints to Servlets.

Use case: a set of navigation links loaded from an external source (e.g. a database), being served by a front controller (so Servlet constraint wouldn't be viable).

Current workaround is to do the authorization checks from a filter, but I'd prefer to delegate that work to the container instead.

I propose to add a method to ServletContext to register/modify web resource collections from inside ServletContextListener and ServletContainerInitializer.

This improvement could be a handy addition in companion with the new Security Spec.



 Comments   
Comment by arjan tijms [ 02/Jul/16 ]

Theoretically this can be done via JACC, but JACC is at the moment far from user friendly and it's difficult to even impossible to install a JACC module/provider.

See http://arjan-tijms.omnifaces.org/2015/04/how-java-ee-translates-webxml.html

Comment by ggam [ 03/Jul/16 ]

That's true for Full Profile Java EE Application Servers, but not for a plain Servlet containers.

What does the Servlet spec say about security configuration? Do you have any clue on how does it currently work on Servlet containers that also integrate with Application Servers (like Undertow-Wildfly and Tomcat-TomEE)? I suppose they manage security in a non standard way and, if JACC is available, delegate to it. The same could be done to cover this issue: use JACC (or Security API) if avaialble and if not, do it in a non standard way.

A similar problem will be faced with the login configs and the Security API. In an Application Server, the Servlet implementation will be able to interface with it and thus delegate the authentication mechanism, but a vendor specific way will still be needed in Servlet only environments.

Comment by arjan tijms [ 03/Jul/16 ]

I suppose they manage security in a non standard way and, if JACC is available, delegate to it.

That's pretty much the idea indeed. Even so, in full profile application servers some products don't delegate by default to JACC. This violates the spec, but since the TCK doesn't check for it, those products still get certified.

In an Application Server, the Servlet implementation will be able to interface with it and thus delegate the authentication mechanism, but a vendor specific way will still be needed in Servlet only environments.

The Servlet spec actually recommends that (standalone) Servlet containers use the standard SPI (JASPIC) for adding authentication mechanisms. Also, this SPI is not a separate product or separate jar, but something that already has to be implemented internally inside a Servlet container. E.g. you can't add a jaspic.jar to a Servlet container like you can add a jsf.jar or a jaxrs.jar, etc.

At the moment every Servlet container actually supports the standard SPI for authentication mechanisms, including Jetty and Tomcat. It was discussed about a year ago to change recommends into must. See SERVLET_SPEC-114

See also SERVLET_SPEC-61 for a response from the spec lead for another request for something that is principally available already via JACC.

Comment by ggam [ 03/Jul/16 ]

I've just found that you can't add constraints to an already created Servlet either. For existing Servlets (obtained via ServletContext#getServletRegistration), you can only add mappings. Only ServletContext#addServlet methods return a Registration.Dynamic which allows to modify the other options.

So it seems that the Expert Group conciously decided not to permit this. It'd be interesting to have some more insight into why this decission was taken.

Until we get an official answer, I think this now belongs to the Security Spec (issue link: JAVAEE_SECURITY_SPEC-39)





[SERVLET_SPEC-158] Clarify the behaviour of the "**" role in security constraints Created: 11/Jul/16  Updated: 11/Jul/16

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

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


 Description   

Under the description of isUserInRole there is the following caveat when it talks about the "**" role:

If the role-name of the security-role to be tested is "**", and the application has NOT declared an application security-role with role-name "**", isUserInRole must only return true

However when discussing declarative constraints later on the spec says

The special role name “**” is a shorthand for any authenticated user independent of role.

No mention is made of special handling of the "**" role if the application has defined an application security role with the same name, which means that according to the letter of the spec the behavior of programmatic constrains and isUserInRole is inconsistent.

I think this should be clarified.






[SERVLET_SPEC-156] Request Cancelled Listener Created: 06/Apr/16  Updated: 10/Aug/16

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

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   

Unlike HTTP/1 it is possible for a HTTP/2 server to know if a connection has failed or if an individual stream has been reset before normal completion. This gives the possibility of adding listeners that can inform an application that their transport is no longer functional.

Typically this would be useful if an application has dispatched an expensive and/or long running request handling process. With HTTP/1 servers, it is not generally possible to know if the connection has been closed without actually attempting IO on it, so even if a client has long ago closed the connection, the first that the expensive/long request handler will know about it is when it completes and attempts to write the response.

With HTTP/2, the connection is always IO active (as it is multiplexed), so any connection failures will be hungrily discovered with a read IOException. There are also explicit frames available to allow a particular stream to be reset.

Thus there is now scope to provide a listener API that will be called if either a connection or request failure is detected.

Something like a new Listener that has to be explicitly set via ServletRequest#addListener on a particular request:

interface ServletRequestCancellationListener

{ void cancelled(ServletRequestCancellationEvent e); }

 Comments   
Comment by pbenedict [ 07/Apr/16 ]

Do you see a tie-in to how the PushBuilder's push() can be cancelled?

Comment by markt_asf [ 07/Apr/16 ]

The new interface works for me.

Comment by stuartdouglas [ 07/Apr/16 ]

I guess we could add the ability to add a ServletRequestCancellationListener to a pushed request, so you receive notification if a push succeeds or fails.

Comment by wenbozhu [ 09/Apr/16 ]

"Abort" might be a better term than cancellation, which implies an explicit client-initiated command (out of the scope of HTTP, IMO).

Comment by gregwilkins [ 09/Aug/16 ]

Note we need to be very precise about the threading behaviour of this callback, as we need to allow multiple threads to be dispatched to the one request at the same time - which I don't think we have done before. This is needed because of the case where a synchronous servlet is in a busy loop or blocked waiting for a remote service, so it needs to be able to receive the callback so it can wake up that processing and terminate it.

We also need to consider how this will interact with async servlets? Will we also allow it to be called in parallel to other async callbacks? Should AsyncListener.onError be called? If it happens simultaneously with a read/write should the Read/Write listener onError also be called?

I believe all the onErrors should be called and in the order:
+ read / write listener onError is called to fail the current operation
+ any AsyncListener.onError is called
+ If and only if AsyncListener.complete has not been called, then ServletRequestCancellationListener.cancelled is called. This can be in parallel with any other dispatch.

This allows us to make the best effort to complete the request cycle normally, and only if the normal error processing has failed to we call the cancelled listener.

Comment by gregwilkins [ 10/Aug/16 ]

An alternative view is that the ServletRequestCancellationListener.cancelled should always be called before any onError callbacks. This would then allow the onError callbacks to be implemented with knowledge of a cancellation and not attempt dispatches or sendError etc.

Comment by stuartdouglas [ 10/Aug/16 ]

I think ServletRequestCancellationListener should basically be a completely separate thing, and it is up to the user to implement it in a thread safe manner (obviously with appropriate warnings in the javadoc).

In terms of invoking the onError callback I think this should just happen as normal, I don't think we should try and define any kind of ordering.

To be honest I think the use case for this listener is quite small. You need to be doing some kind of long running work that can be interrupted in some way. If you are reading from or writing to the transport you will be notified immediately anyway. I am really not sure if the use case is strong enough to make this part of the spec.





[SERVLET_SPEC-145] Specify default URL encoding Created: 04/Oct/15  Updated: 05/Sep/16

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

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


 Description   

There seems to be disagreement among specification implementors what default URL encoding the specification requires. Some implementors interpret the specification requires ISO-8859-1. Others interpret the specification not requiring anything and follow the W3C recommendation and use UTF-8. Some have a "strict servlet compliance" flag that switches the default to ISO-8859-1.

Ideally the specification makes it clear what the default is and verifies it in the TCK.

For a discussion follow this thread:

https://java.net/projects/servlet-spec/lists/users/archive/2015-08/message/41

and check these implementation documentation

https://wiki.eclipse.org/Jetty/Howto/International_Characters
http://wiki.apache.org/tomcat/FAQ/CharacterEncoding



 Comments   
Comment by stuartdouglas [ 06/Apr/16 ]

I think it would actually be useful to allow this to be specified in web.xml

Comment by markt_asf [ 07/Apr/16 ]

This isn't something that can be defined in web.xml since there must be a single encoding used for URLs. The URL needs to be decoded before mapping to a web application.

I'd be fine with making the default UTF-8.

Comment by stuartdouglas [ 05/Sep/16 ]

There are really three different areas where encoding is used:

  • URL encoding: The current spec says nothing about this
  • Request encoding: The spec says this must default to ISO-8859-1
  • Response encoding: The spec says this must default to ISO-8859-1

As you correctly point out it is not really possible to make URL encoding application specific, as it needs to be a container level setting. IMHO we should do the following:

  • Recommend that containers use UTF-8 as a default for URL encoding, as per rfc3986
  • Add <default-encoding> to web.xml to control the default request and response encoding (I don't think these need to be controlled separately).
  • Potentially change the default encoding to UTF-8. Even though this will break backwards compatibility to some extent it can be fixed by adding the <default-encoding> element. HTML5 changed this default to UTF-8, and as time goes by ISO-8859-1 will become less and less relevant
Comment by stuartdouglas [ 05/Sep/16 ]

I guess the request and response encoding I mention should really have their own issue. The linked email discussion talks about both, but they are really two separate issues.





[SERVLET_SPEC-160] Deep Object Mutations and Session Replication Created: 02/Sep/16  Updated: 02/Sep/16

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   

Make it easier for applications that store data structures in the session, and mutate those data structures during the scope of a request, to ensure that the changes to the data structure are replicated with session replication correctly.






[SERVLET_SPEC-161] Allow encoding to be set from deployment descriptor Created: 07/Sep/16  Updated: 07/Sep/16

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   

SD> Request/Response Encoding

SD> At the moment the spec explicitly states that these default to
SD> ISO-8859-1, which made sense at the time as this was the default
SD> character encoding for HTML4. HTML5 has changes this however and now
SD> defaults to UTF-8.

SD> To address this I think we need to allow the default to be controlled
SD> in web.xml via a <default-encoding> element. This element will only
SD> affect the request and response encoding, and will override any spec
SD> mandated default. Obviously if the encoding is explicitly specified
SD> the default will not be used.



 Comments   
Comment by Ed Burns [ 07/Sep/16 ]

GW> So they could just be <request-encoding> and <response-encoding>, with
GW> documentation that says that the encoding set by these is overridden by the
GW> programmatic methods: setCharacterEncoding, setContent-Type and/or
GW> setLocale.

Comment by Ed Burns [ 07/Sep/16 ]

Section 3.11 of the prose document must be updated. It currently says:

Request data encoding
Currently, many browsers do not send a char encoding qualifier with the Content- Type header, leaving open the determination of the character encoding for reading HTTP requests. The default encoding of a request the container uses to create the request reader and parse POST data must be “ISO-8859-1” if none has been specified by the client request. However, in order to indicate to the developer, in this case, the failure of the client to send a character encoding, the container returns null from the getCharacterEncoding method.
If the client hasn’t set character encoding and the request data is encoded with a different encoding than the default as described above, breakage can occur. To remedy this situation, a new method setCharacterEncoding(String enc) has been added to the ServletRequest interface. Developers can override the character encoding supplied by the container by calling this method. It must be called prior to parsing any post data or reading any input from the request. Calling this method once data has been read will not affect the encoding.





[SERVLET_SPEC-162] Make it possible to participate in the component instance creation Created: 08/Sep/16  Updated: 08/Sep/16

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

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


 Description   

The spec requires the implementations to support injection and interception for Servlets, Filters, Listeners and HttpUpgradeHandlers. Still it does not provide any SPI which would allow to participate in the component instance creation.

This is usually not a problem for Java EE servers where integration is mostly based on implementation-specific features.

However, outside Java EE the CDI integration code (for example Weld Servlet) must leverage non-portable SPIs, such as io.undertow.servlet.api.InstanceFactory<T> and org.apache.tomcat.InstanceManager.

It might be useful to provide a portable SPI for this.






[SERVLET_SPEC-37] Update Cookie class and other specifications for RFC 6265 Created: 29/Mar/12  Updated: 08/Sep/16

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

Comment by markt_asf [ 06/Sep/16 ]

Ping. This really needs to get into Servlet 4.0

Comment by christopherschultz [ 08/Sep/16 ]

+1 for updating and clarifying the spec. If Servlet 4.0 still contains a requirement to support RFC2019 (and nothing more recent), then the Java ecosystem will continue to suffer this confusion for another few years.





[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: 4
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-163] decoding on getContextPath of HttpServletRequest and ServletContext Created: 12/Sep/16  Updated: 20/Sep/16

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   

The first paragraph of the spec for getContextPath() method on HttpServletRequest states():

"The container does not decode this string."

The first paragraph of the corresponding method on ServletContext does not have this statement, but is otherwise semantically equivalent.

This JIRA seeks to have the statement added to ServletContext.getContextPath().



 Comments   
Comment by gregwilkins [ 20/Sep/16 ]

rather than have that statement added to ServletContext.getContextPath(), there are other alternatives:
+ document the different behaviour in the javadoc.
+ accept that the decoding on the Request version was a cut and paste error and remove.
+ accept that the decoding on the Request version was a cut and paste error and replace with "The path returned is the containers preferred encoding of the context path string", so as to limit the applications exposure to non-normalized client supplied strings.





[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-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-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-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-149] Eliminate talk of "default" context Created: 19/Nov/15  Updated: 19/Nov/15

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

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


 Description   

With 4.0, web.xml is introducing a <default-context-path> element (SERVLET_SPEC-137). To prevent confusion, the Javadoc for ServletContext#getContextPath should stop mentioning the "default" context as a synonym for the "root" context. The latter should only be mentioned.






[SERVLET_SPEC-150] Eliminate talk of "default" context Created: 19/Nov/15  Updated: 20/Nov/15

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

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


 Description   

With 4.0, web.xml is introducing a <default-context-path> element (SERVLET_SPEC-137). To prevent confusion, the Javadoc for ServletContext#getContextPath should stop mentioning the "default" context as a synonym for the "root" context. The latter should only be mentioned.



 Comments   
Comment by pbenedict [ 19/Nov/15 ]

Please delete this ticket. My apologies. Wrong spec project.

Comment by Lukas Jungmann [ 20/Nov/15 ]

moved to the right project





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

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.



 Comments   
Comment by Arend v. Reinersdorff [ 20/Dec/15 ]

Update for Servlet 4.0 Spec, Early Draft Review:
page 201, 14.5.1 A Basic Example
page 202, 14.5.2 An Example of Security





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

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



 Comments   
Comment by Arend v. Reinersdorff [ 20/Dec/15 ]

Update for Servlet 4.0 Spec, Early Draft Review:

Broken links to java.sun.com:
page 61 - http://java.sun.com/products/jsp - new: http://www.oracle.com/technetwork/java/index-jsp-138231.html
page 126 - http://java.sun.com/products/jsp - new: http://www.oracle.com/technetwork/java/index-jsp-138231.html
page 129 - 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 194 - http://www.jcp.org/en/jsr/detail?id=109]
page 209 - http://jcp.org/jsr/detail/109.jsp]

Example links should use example.com instead of real domains:
page 53 - 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 125 - http://www.mycorp.com/catalog - better: http://www.example.com/catalog
page 242 - http://java.sun.com/products/servlet/index.html - better: http://java.example.com/products/servlet/index.html
page 242 - https://javashop.sun.com/purchase - better: https://example.com/purchase

Comment by jagdeesh [ 24/Dec/15 ]

updates on broken link.
If i am wrong please correct me for.
pg : 129 - http://java.sun.com/j2se/1.4/docs/guide/extensions/ - new:
http://docs.oracle.com/javase/8/docs/technotes/guides/extensions/index.html





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

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

Type: Bug Priority: Minor
Reporter: Anthony Vanelverdinghe 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.



 Comments   
Comment by stuartdouglas [ 07/Apr/16 ]

I don't think this needs to be specified. If CDI is enabled the container can create the Servlet even if it does not have a default constructor via constructor injection.

Comment by Anthony Vanelverdinghe [ 07/Apr/16 ]

Good point about the constructor's signature, I hadn't considered CDI at the time. However, I believe it's needed to specify error conditions and exceptions, analog to what is already specified for initialization (2.3.2.1) and request handling (2.3.3.2). For example, is a container allowed to attempt instantiation again when a previous attempt failed? And if so, what happens if the constructor throws an UnavailableException? Is it treated the same way as during initialization, or is it treated just as any other kind of failure?

Here's a proposed text - adapted from 2.3.2.1 - for instantiation:

After loading the Servlet class, the container instantiates it for use. If instantiation fails, the container throws a ServletException.

A new instance may be instantiated by the container after a failed instantiation. The exception to this rule is when an UnavailableException (thrown by the servlet's constructor) indicates a minimum time of unavailability, and the container must wait for the period to pass before creating a new servlet instance.

Comment by pbenedict [ 07/Apr/16 ]

Even if the constructor completes normally, the specification leaves undefined the kind of exception thrown if CDI cannot complete injection. Is it a regular ServletException so the container can instantiate again or is it UnavailableException because failed injection is likely a fatal error?

Comment by markt_asf [ 07/Apr/16 ]

I'd lean towards any instantiation failure being treated as permanent unless it is an UnavailableException with a specific time frame in which case that should be used.





[SERVLET_SPEC-130] Please add servlet request attribute for SSL/TLS protocol Created: 08/Apr/15  Updated: 09/May/16

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

Type: Improvement Priority: Minor
Reporter: christopherschultz Assignee: Unassigned
Resolution: Unresolved Votes: 4
Labels: security
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Since the early days of the servlet specification, the following request attributes have been provided to applications wishing to check the details of the remote user's SSL/TLS connection:

javax.servlet.request.cipher_suite
javax.servlet.request.key_size
javax.servlet.request.ssl_session_id
javax.servlet.request.X509Certificate

It would also be nice to be able to see the SSL/TLS protocol (e.g. SSLv3, TLSv1, TLSv1.2, etc.).

I propose the following request attribute to be added to the specification and required by compliant containers:

javax.servlet.request.ssl_protocol (consistent with existing .ssl_* attribute names)
or
javax.servlet.request.tls_protocol (consistent with likely future protocols)
or
javax.servlet.request.secure_protocol (protocol-name agnostic)

The list of acceptable values should match the JVM's naming scheme for SSL/TLS protocol, but not be restricted to the protocols supported by the underlying Java Runtime Environment (in the event that a crypto provider other than JSSE – e.g. OpenSSL, etc. – is being used to provide the secure connection instead of the JRE).

The level-of-effort to modify the specification should be minimal, and the burden on container implementers should be similarly minimal, since the existing request attributes must already be populated in the request attributes, and the SSL/TLS protocol is readily available from the same source as the aforementioned attribute values.



 Comments   
Comment by markt_asf [ 08/Apr/15 ]

+1

No strong perference on attribute name.

Comment by Eugene Chung [ 09/Apr/15 ]

+1

Comment by christopherschultz [ 04/Mar/16 ]

Almost a year with no feedback, the Servlet 4.0 grows ever closer. This seems like a very small and very useful request.

Comment by violetagg [ 09/May/16 ]

+1





[SERVLET_SPEC-159] Clarify setHeader() and null or empty string arguments Created: 02/Sep/16  Updated: 12/Sep/16

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

Type: Improvement Priority: Minor
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 spec for HttpServletResponse.setHeader() does not say what to do if one or both of the arguments is null or empty.

https://docs.oracle.com/javaee/7/api/javax/servlet/http/HttpServletResponse.html#setHeader-java.lang.String-java.lang.String-



 Comments   
Comment by Ed Burns [ 07/Sep/16 ]

setHeader(null, anything) is a no-op.
setHeader(anything, null) removes the header
setHeader(anything, "") makes the header "anything" have an empty value. If there is an existing value for header anything, that value is replaced with the empty value.

If a header has been removed in this way, containsHeader() for that header returns false.

containsHeader(null) always returns false.

Comment by Ed Burns [ 12/Sep/16 ]

Add this text:

"Containers may still add or modify headers before the response is
committed. These will generally be headers that are required at a
protocol level."





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






[SERVLET_SPEC-148] HttpServletRequest#getPushBuilder missing @since 4.0 Created: 18/Nov/15  Updated: 18/Nov/15

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

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


 Description   

Missing @since 4.0






Generated at Mon Sep 26 07:11:10 UTC 2016 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.