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

Status: Resolved
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: Duplicate 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
Duplicate
is duplicated by 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-116] Take ownership of CDI-related beans from CDI spec Created: 19/Nov/14  Updated: 21/Nov/14  Resolved: 21/Nov/14

Status: Resolved
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: Works as designed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

CDI Spec section 3.8 [1] places some requirements on CDI implementations when running with Servlet. To better suit user desires for modularity these requirements are better met by moving them to the Servlet spec. Specifically,

A servlet container must provide the following built-in beans, all of which have qualifier @Default:

a bean with bean type javax.servlet.http.HttpServletRequest, allowing injection of a reference to the HttpServletRequest

a bean with bean type javax.servlet.http.HttpSession, allowing injection of a reference to the HttpSession,

a bean with bean type javax.servlet.ServletContext, allowing injection of a reference to the ServletContext,

These beans are passivation capable dependencies, as defined in Passivation capable dependencies.

To put these items in the Servlet spec, we may have to couch them in terms similar to, "when running in an environment that also supports CDI..."

[1] http://docs.jboss.org/cdi/spec/1.2/cdi-spec.html#additional_builtin_beans



 Comments   
Comment by Ed Burns [ 19/Nov/14 ]

See <https://github.com/weld/core/blob/master/impl/src/main/java/org/jboss/weld/bean/builtin/ee/HttpServletRequestBean.java> for some implementation details from Weld.

Some notes from IRC

<edburns> antoine_sd: And the "bean with bean type javax.faces.servlet.http.HttpServletRequest" portion of the requirement is satisfied precisely by this declaration: "CreationalContext<HttpServletRequest>"? Is that correct?
<jharting> edburns: no, the requirement you quoted is met by HttpServletRequestBean.getTypes() returning a set containing HttpServletRequest.class
<edburns> jharting: Thanks, that exactly what I was looking for.
<jharting> edburns: it's not obvious as it is a bit hidden deeper in the class hierarchy
<edburns> jharting: I suppose getTypes() is inherited from AbstractStaticallyDecorableBuiltInBean<HttpServletRequest>?

Comment by Ed Burns [ 19/Nov/14 ]

Corresponding issue in CDI tracker: https://issues.jboss.org/browse/CDI-492.

Comment by Ed Burns [ 21/Nov/14 ]

>>>>> On Wed, 19 Nov 2014 15:55:43 -0500 (EST), Stuart Douglas said:

[...]

SD> I think however there may be some backwards compatibility issues for
SD> the standalone servlet container case.

SD> Say I have an application that packages Weld (or OWB) that I have
SD> deployed on a Servlet 3.1 container, and I now want to move it to a
SD> Servlet 4.0 container. The older version of Weld will still provide
SD> the HttpServletRequest beans (as it is required to do by spec) and
SD> the servlet container will also provide these beans (as we are
SD> required to do by spec) and as a result if you try and inject them
SD> you will get a bean resolution error as two beans resolve to the
SD> injection point.

SD> This also works in reverse, if you deploy a new version of CDI to an
SD> older servlet container then no beans will be registered, however I
SD> think this is less of an issue.

SD> For servers that don't actually provide CDI API jars there may also
SD> be some linking issues. The producers need to be linked against the
SD> CDI API which in this case will be provided by the deployment, so it
SD> won't really be possible to just have them as a global library.

>>>>> On Fri, 21 Nov 2014 14:06:24 +1100, Greg Wilkins said:
[...]

GW> I share Stuarts concerns about classloading confusion. More over,
GW> I'm concerned that by making CDI to servlet mapping a responsibility
GW> of the servlet container, then we are going to have to do a
GW> container to CDI adaptation for every CDI implementation out there.

GW> The servlet specification already provides servlet container initializers,
GW> which have all the power required for CDI implementations to implement
GW> these CDI v Servlet cross concerns. Thus I think these things must
GW> remain a CDI impl responsibility as they are able to write container
GW> portable code that will handle these concerns. The inverse is not true if
GW> we make them container concerns.

Excellent points. I will use these to push back on
CDI-492-FobStuffToServlet. I will provisionally close this issue for
now at least.





[SERVLET_SPEC-30] Configure default behavior of url pattern not covered by security constraint Created: 17/Jan/12  Updated: 05/Mar/13  Resolved: 05/Mar/13

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

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


 Description   

If an url pattern is not covered by security-constraint, then the default behavior is "permit all".
One would like to configure the default behavior to be "deny all".



 Comments   
Comment by gregwilkins [ 31/Jan/12 ]

Note that this used to be very difficult to do because it was impossible to add a constraint that forbid /* and then to add other constraints that relaxed the criteria on other URIs - because it was impossible to explicitly match "/".

Now with the "" pattern matching root, it is possible to use normal constraints to implement a deny by default and permit by specific pattern approach. So maybe we don't need a change in the spec for this.

Comment by Shing Wai Chan [ 05/Mar/13 ]

Add Section 13.8.4, Uncovered HTTP Protocol Methods.
Add deny-uncovered-http-methods in web.xml schema.





[SERVLET_SPEC-33] Need to clarify the behavior of HttpServletRequest.getPart/getParts Created: 08/Mar/12  Updated: 01/Aug/12  Resolved: 01/Aug/12

Status: Resolved
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: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

In the javadoc of httpServletRequest.getPart/getParts, it does not mention the behavior of calling these API when there is no @MultipartConfig and multipart-config in deployment descriptors.

One should exception in this case. UnsupportedOperationException? IllegalStateException?



 Comments   
Comment by Christian Ludt [ 25/Mar/12 ]

Both current javadocs for getPart() and getParts() specify that a ServletException is to be thrown:

Throws:
java.io.IOException - if an I/O error occurred during the retrieval [...]
ServletException - if this request is not of type multipart/form-data
IllegalStateException - if the request body is larger than maxRequestSize, or any Part in the request is larger than maxFileSize

Comment by Shing Wai Chan [ 26/Jul/12 ]

The ServletException is thrown when the request is not of type multipart/form-data.
The scenario in the description above is when there is no multipart configuration.
So, one still need to clarify this case.

Comment by markt_asf [ 28/Jul/12 ]

Rather than an Exception, returning null / an empty collection is also an option.

I prefer IllegalStateException over UnsupportedOperationException but have no string preference between throwing an Exception and returning null / an empty collection.

Comment by Shing Wai Chan [ 01/Aug/12 ]

Sending src/main/java/javax/servlet/http/HttpServletRequest.java
Transmitting file data .
Committed revision 55270.





[SERVLET_SPEC-32] Need to clarify when the servlet container will process the file upload Created: 06/Mar/12  Updated: 08/Mar/12  Resolved: 06/Mar/12

Status: Resolved
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: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

In section of 3.2 of Servlet 3.0 spec, servlet container process multipart/form-data for file uploaded when @MultipartConfig is annotated with the corresponding servlet.

This is not correct as one also need to consider the multipart-config element in web.xml.



 Comments   
Comment by Shing Wai Chan [ 06/Mar/12 ]

Sending requestobject.fm
Sending status.fm
Transmitting file data ..
Committed revision 22.

Comment by Shing Wai Chan [ 08/Mar/12 ]

Sending requestobject.fm
Transmitting file data .
Committed revision 24.





[SERVLET_SPEC-28] @WebServlet annotation does not support the 'enabled' attribute specified by the Servlet 3.0 specification Created: 16/Nov/11  Updated: 23/Jul/12  Resolved: 23/Jul/12

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

Type: Improvement Priority: Major
Reporter: Amy Roh Assignee: Shing Wai Chan
Resolution: Invalid Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Dependency
blocks GLASSFISH-17721 @WebServlet annotation does not suppo... Resolved

 Description   

See http://java.net/jira/browse/GLASSFISH-17721

"The Servlet 3.0 specification in section 8.2.3 sub part 3 describes "If a servlet is disabled using the enabled element introduced in the web.xml then the servlet will not be available at the url-pattern specified for the servlet".

The WebServletHandler.java deployment annotation handler does not support then enabled element and it should since it is part of the web.xml specification for the <servlet> element."



 Comments   
Comment by rojkov [ 07/Dec/11 ]

I think since this requires recompilation, one can simply comment out the annotation to the same effect.

Comment by emailnbw [ 07/Dec/11 ]

@rojkov -

I don't understand your comment. Are you suggesting a 'work around' or a way to test proposed changes?

Comment by rojkov [ 07/Dec/11 ]

@emailnbw enable in web.xml makes sense because you might want to disable a servlet without recompiling, repackaging and redeploying. Adding it to the annotation means that recompilation, repackaging and redeployment is required for the setting to take effect. If the servlet isn't needed it should be either removed from the source or have @WebServlet commented out. The only value the change provides is consistency.

Comment by emailnbw [ 07/Dec/11 ]

@rojkov -

Thanks for the clarification, I understand what you were saying now. So the use case I had in mind which is what got me to investigate this in the first place is that our web application does not have a web.xml deployment descriptor. We would like to use the annotation to affect a disabled servlet on deployment which will then be programmatically enabled at a time subsequent to deployment.

Comment by rojkov [ 07/Dec/11 ]

I see. This seems to add another requirement for a container to monitor changing annotations. The way I interpret the spec is that examining of annotations takes place at starting of the context.

Comment by emailnbw [ 07/Dec/11 ]

The container will scan for the annotations during the deployment context, it will find the annotated web servlet, which it does in the current scheme, but it would also possibly find an 'enable' attribute on that WebServlet annotation, e.g.:

@WebServlet(asyncSupported = false, name = "HelloServlet", urlPatterns =

{"/hello"}

, enabled = false)

It would deploy the servlet in a disabled state the same way the container would have done had this been specified in the web.xml.

Then some time later external code would enable the web servlet (perhaps via a ReST endpoint the web app provides or a MXBean). The value of the enabled annotation would remain the same through out this process so there is no need to monitor for changing annotations. However, it does mean the container would need to support programmatically enabling/disabling a servlet after deployment. I haven't looked at the existing code path that takes care of enable/disable of a servlet on deployment to know what is involved there.

Comment by Shing Wai Chan [ 18/Jan/12 ]

So having the annotation attribute does not solve your issue, you need a way to enable/disable a given servlet in the runtime. In Servlet 3.0, one can only modify the servlet registration before or on context initialization.

Comment by Shing Wai Chan [ 23/Jul/12 ]

Adding an 'enabled' attribute to @WebServlet does not solve the issue described above.
According to Servlet 3.0, one cannot enable a servlet after the context initialization.





[SERVLET_SPEC-10] Character encoding setting after ServletResponse#reset Created: 20/Sep/11  Updated: 13/Jan/12  Resolved: 13/Jan/12

Status: Resolved
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: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

From javadoc, ServletResponse#reset will clear any data that exists in the buffer as well as the status code and headers. If the response has been committed, this method throws an IllegalStateException.

Once the headers are cleared, so is the charset in Content-Type.
If the getWriter() is already called, then according to javadoc of ServletResponse#setCharacterEncoding, one cannot set the encoding. In other words, only the default charset (in a given implementation) can used in this case.



 Comments   
Comment by markt_asf [ 21/Sep/11 ]

I assume that the proposed solution is that calling reset() also resets whatever tracking mechanism is used to determine that getWriter() or getOutputStream() has been called and thereby allowing the user to effectively start again.

Comment by Shing Wai Chan [ 21/Sep/11 ]

If we reset the state for determining whether getWriter() and getOutputStream() has been called, then we need to clarify what happens to existing Writer or OutputStream. Then we need to clarify the behaviors of the existing writer or outputstream.

Comment by markt_asf [ 22/Sep/11 ]

The spec should state that if the response is reset the Writer/OutputStream should no longer be used. Behaviour if there are used is undefined / throws ISE (I have have a slight preference for undefined since that means less work for me ).

As it happens, Tomcat will happily allow the Writer or OutputStream to be re-used although getWriter(), reset(), getOutputStream() will allow the Writer and OutputStream to be used together which might lead to some strange results.

Mark

Comment by Shing Wai Chan [ 13/Jan/12 ]

Sending javax.servlet/src/main/java/javax/servlet/ServletResponse.java
Transmitting file data .
Committed revision 52096.

Sending responseobject.fm
Sending status.fm
Transmitting file data ..
Committed revision 6.





[SERVLET_SPEC-27] sendRedirect Javadoc prevents use of protocol relative URLs Created: 07/Oct/11  Updated: 19/Jan/12  Resolved: 19/Jan/12

Status: Resolved
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: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

The Javadoc for sendRedirect() is quite clear that a URL starting with '/' should be treated as relative to the server root. However, that precludes the use of protocol relative URLs that start with '//'. See [1] for details of why these might be useful. While there are clearly arguments for and against protocol relative URLs, I don't think we should preclude their use and therefore the Javadoc for sendRedirect should be amended to allow for them.

[1] http://blog.httpwatch.com/2010/02/10/using-protocol-relative-urls-to-switch-between-http-and-https/



 Comments   
Comment by Shing Wai Chan [ 19/Jan/12 ]

Sending src/main/java/javax/servlet/http/HttpServletResponse.java
Transmitting file data .
Committed revision 52212.





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

Status: Resolved
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: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Related
is related to SERVLET_SPEC-123 Clarify META-INF/resources in a jar i... Resolved

 Description   

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



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

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

Comment by markt_asf [ 07/Feb/13 ]

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

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





[SERVLET_SPEC-17] Clarify required behaviour when an Async listener throws an exception Created: 04/Oct/11  Updated: 15/Dec/12  Resolved: 15/Dec/12

Status: Resolved
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: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

The behaviour on an exception is currently undefined. It would be helpful if the spec defined the expected behaviour in this case. I guess the options are:

  • any recoverable exception to be swallowed/logged and the subsequent listeners fired
  • the request is placed in to the error state


 Comments   
Comment by Shing Wai Chan [ 15/Dec/12 ]

Sending servletobjects.fm
Sending status.fm
Transmitting file data ..
Committed revision 49.





[SERVLET_SPEC-15] Provide the ability for sendRedirect() to control the status code used Created: 04/Oct/11  Updated: 29/Dec/13  Resolved: 29/Dec/13

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

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


 Description   

There are a range of status codes that a developer might want to use with sendRedirect (302,303,307). Currently, sendRedirect() always issues 302s. It would be helpful to extend the API to allow the developer to control which status code is used.



 Comments   
Comment by markt_asf [ 29/Dec/13 ]

This is duplicated (in much more detail) by SERVLET_SPEC-74





[SERVLET_SPEC-14] Require FORM auth to issue 303 redirects Created: 04/Oct/11  Updated: 01/Mar/13  Resolved: 01/Mar/13

Status: Resolved
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: Fixed Votes: 1
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

See https://issues.apache.org/bugzilla/show_bug.cgi?id=49779 for an example of why this would be useful.



 Comments   
Comment by monzillo [ 10/Jan/13 ]

I downloaded the app, ported it, and ran it on Glassfish, and did not see the reported problem.
That said, constraint processing and FBL are areas where glassfish and tomcat differ in their implementations.

In any event, I took a closer look at FBL, and I can see how there is a problem (with FBL) which likely is independent of implementation.

As I understand FBL it works generally as follows (leaving out some failure cases like failure of password validation).

1. a request is made to a resource requiring authentication.

2. the container calls the authentication system which saves the request, and the login page is returned to the user.

3. the user fills in the login page and submits its contents in a POST request to j_security_check.

4. the container routes j_security_check to the authentication system which validates the username and password obtained from the post request, and then restores the uri of the saved request and then redirects the post request to the restored uri.

5. the browser repeats the restored request to the restored resource url (the http verb used by the browser depends on the verb used in step 4)

6. if the container determines that the repeated request requires authetication, it calls the authentication system; in which case, the authentication system notices that it has already authenticated this request, so it binds the principal to the request, and restores the details from the original saved request (including the http verb)

7. In either case, the container determines if the called principal (which may be null if the authentication system was skipped in step 6) is authorized to access the resource using verb of the request (which depends on both the way the redirect was done in step and whether the verb used by the browser in step 6, required authentication).

if the redirect of step 4 is done with a 302, then the restored request should be repeated (by the browser with POST, since it is a redirect in response to the POST of the login form. If the original request was done with a verb other than POST, then there is always the possibility that that verb required authentication, and POST does not; in which case the authenticator would not be called in step 6, the verb would not be restored, the caller principal would not be set, and the access check would presumably pass, although the wrong method of the resource would likely be called.

Conversely if the redirect of step 4 is done with a 303, then the restored request should be repeated with a GET; which can result in similar problems if the original request was done with a verb other than GET, and that verb requires authentication while GET does not.

I am not sure how to completely resolve this, but I think the following are true. a 303 redirect should be used when the original request came in with GET. This will ensure that the original request and the repeat following redirect are identical in terms or checked url and http verb.
a 302 redirect should be used when the original request cam in with post. If the request came in on any verb other than GET or POST, then the authenticator should fail if neither GET or POST have been configured to require authentication (at the request pattern). Otherwise 302 or 330 should be used depending on whether POST or GET require authentication.

If the dialog is short-circuited, for example by starting with a GET of the login page, or of a GET or POST to j_security_check, then I believe the convention is to redirect the request to the context root of the app, in which case, either redirection code can likely be accomodated.

Comment by markt_asf [ 12/Jan/13 ]

I agree with all of the analysis above with a few minor tweaks:

I'd used 307 rather than 302 for HTTP/1.1 clients to be unambiguous.

I wonder if the following option is viable:

  • Always use 303 redirects
  • Always pass GET requests through the FORM authenticator
  • If the resource is protected for GET - proceed as currently
  • If the resource is not protected for GET, check if there is a saved request to be restored
  • If there is, restore it along with the original verb
  • If not, carry on
Comment by monzillo [ 14/Jan/13 ]

Yes, I think so...but as i'm sure you know, the container runtime, which in our cases likely includes some variant of AuthenticatorBase, mostly just decides when to call the configured authenticator (based on evaluating constraints), while leaving it up to the authenticator to know how to deal with details/problems like the one we are discussing.

In this case, we are basically saying that (at least) one specific authenticator can't function properly unless it is called on every request (for which an caller identity has not yet been established), and that (when the runtime calls the authenticator on each request) the runtime will either need to pass the authenticator more info (describing the nature of constraints that apply to the call), or the authenticator will need to perform the constraint determination that would otherwise have been done by the runtime.

Since the runtime currently handles all authenticators in (basically) the same way, such a change might need to effect the implementation of all the existing authenticators, or at least we would need to establish a way for the runtime to be able to ask the authenticator if it must be called on every request. Since all the authenticators extend BasicAuthenticator, we could probably do this by adding a method to BasicAuthenticator, that could be overriden by only those authenticators that need to be called independent of constraint.

Aslo, and fwiw, the Servlet Profile of jsr 196 requires; that the configured auth context be called on every request, and the context of the request informs the auth module, as to whether or not the current request is subject to an auth contraint.

Comment by Shing Wai Chan [ 01/Mar/13 ]

The spec has been updated to use 303 appropriately for HTTP/1.1.
See section 13.6.3 for Servlet 3.1 PFD.





[SERVLET_SPEC-13] Make session fixation protection part of the spec Created: 04/Oct/11  Updated: 19/Sep/12  Resolved: 19/Sep/12

Status: Resolved
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: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

One of the options for providing protection against session fixation is to change the ID of a session on authentication. It would be good if something along the lines of a changeId() method could be added to the session interface to enable custom security solutions to do this easily. An associated event for sessions listeners would also be required.



 Comments   
Comment by markt_asf [ 04/Oct/11 ]

On a related note we may want to consider an option to control if this happens when using container provided authentication.

Comment by janbartel [ 06/Feb/12 ]

Access will be needed to the current request, and also the current response in order to effectively change the session id.

So I propose we add the following to the HttpSession object:

public String changeId (HttpServletRequest request, HttpServletResponse response);

where the return value is the new sessionId.

Comment by gregwilkins [ 06/Feb/12 ]

Note also that we have to consider shared session IDs with cross context dispatch.

If a server is working with cross context dispatch, then many contexts can have the same session ID pointing to different sessions. Changing the session ID on one context will have to change the session ID for all contexts (just as invalidating on one will invalidate on all).

cheers

Comment by Shing Wai Chan [ 14/Sep/12 ]

Incremental fixes:
Committed revision 42.

Modified Paths:
---------------
trunk/servletcontext.fm
trunk/javaEE.fm
trunk/eod-pluggability.fm
trunk/status.fm
trunk/events.fm
trunk/requestobject.fm

Comment by Shing Wai Chan [ 19/Sep/12 ]

Sending sessions.fm
Sending status.fm
Transmitting file data ..
Committed revision 44.





[SERVLET_SPEC-136] Deprecated HttpServletRequestWrapper#isRequestedSessionIdFromUrl() Created: 17/Aug/15  Updated: 18/Aug/15  Resolved: 18/Aug/15

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

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


 Description   

HttpServletRequest#isRequestedSessionIdFromUrl() is deprecated in Servlet 2.1. But the corresponding method in HttpServletRequestWrapper is not deprecated. The HttpServletRequestWrapper#isRequestedSessionIdFromUrl() method should be deprecated.



 Comments   
Comment by Shing Wai Chan [ 18/Aug/15 ]

Sending src/main/java/javax/servlet/ServletContext.java
Sending src/main/java/javax/servlet/ServletRequestWrapper.java
Sending src/main/java/javax/servlet/SingleThreadModel.java
Sending src/main/java/javax/servlet/UnavailableException.java
Sending src/main/java/javax/servlet/http/HttpServletRequest.java
Sending src/main/java/javax/servlet/http/HttpServletRequestWrapper.java
Sending src/main/java/javax/servlet/http/HttpServletResponse.java
Sending src/main/java/javax/servlet/http/HttpServletResponseWrapper.java
Sending src/main/java/javax/servlet/http/HttpSession.java
Sending src/main/java/javax/servlet/http/HttpSessionContext.java
Sending src/main/java/javax/servlet/http/HttpUtils.java
Transmitting file data ...........
Committed revision 64060.





[SERVLET_SPEC-142] Use Java SE 8 default methods for listeners Created: 23/Sep/15  Updated: 06/Oct/15  Resolved: 06/Oct/15

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

Type: Bug Priority: Major
Reporter: Ed Burns Assignee: Shing Wai Chan
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 0 minutes
Time Spent: 39 minutes
Original Estimate: Not Specified

Attachments: Zip Archive SERVLET_SPEC-142.zip    

 Description   

Consider these listener APIs in Servlet:

./javax/servlet/AsyncListener.java
./javax/servlet/ReadListener.java
./javax/servlet/ServletContextAttributeListener.java
./javax/servlet/ServletContextListener.java
./javax/servlet/ServletRequestAttributeListener.java
./javax/servlet/ServletRequestListener.java
./javax/servlet/WriteListener.java
./javax/servlet/http/HttpSessionActivationListener.java
./javax/servlet/http/HttpSessionAttributeListener.java
./javax/servlet/http/HttpSessionBindingListener.java
./javax/servlet/http/HttpSessionIdListener.java
./javax/servlet/http/HttpSessionListener.java

Most of the methods in most of those classes can have sensible no-op implementations using the Java SE 8 default methods.



 Comments   
Comment by Shing Wai Chan [ 24/Sep/15 ]

The attachment above basically adding no-ops default to all methods in listeners interfaces.
I think we should look at them one by one.

For instance, HttpSessionIdListener has only one method. Do we really need a default there?

For WriteListener, both #onWritePossible and #onError are essential. Should we have empty method body there? Do we want to ignore all errors by default? Is it a good default?
Similarly for ReadListener.
Note that AsyncListener has a #onError method there, too.

Comment by Ed Burns [ 24/Sep/15 ]

Shing-wai, absolutely we need to look at each one individually.

Let's partition the work of doing that in two, 6 each. Please check out the topic branch and make the changes you feel necessary. Thanks!

Shing-wai

./javax/servlet/http/HttpSessionIdListener.java
./javax/servlet/WriteListener.java
./javax/servlet/ReadListener.java
./javax/servlet/AsyncListener.java
./javax/servlet/http/HttpSessionBindingListener.java
./javax/servlet/http/HttpSessionListener.java

Ed

./javax/servlet/ServletContextAttributeListener.java
./javax/servlet/ServletContextListener.java
./javax/servlet/ServletRequestAttributeListener.java
./javax/servlet/ServletRequestListener.java
./javax/servlet/http/HttpSessionActivationListener.java
./javax/servlet/http/HttpSessionAttributeListener.java

Comment by Ed Burns [ 24/Sep/15 ]

Ok, I reviewed all six in my list

./javax/servlet/ServletContextAttributeListener.java
./javax/servlet/ServletContextListener.java
./javax/servlet/ServletRequestAttributeListener.java
./javax/servlet/ServletRequestListener.java
./javax/servlet/http/HttpSessionActivationListener.java
./javax/servlet/http/HttpSessionAttributeListener.java

and I conclude they are ok as is. I'll assign the issue to you to review the remainder.

Comment by Shing Wai Chan [ 06/Oct/15 ]

Per discussion with EG, we will do the following:
. We can add no-op default methods to all of the methods in
javax.servlet:
ServletContextAttributeListener, ServletContextListener,
ServletRequestAttributeListener, ServletRequestListener
javax.servlet.http:
HttpSessionActivationListener, HttpSessionAttributeListener,
HttpSessionBindingListener, HttpSessionListener

2. We will "not" add no-op default method to javax.servlet.http.HttpSessionIdListener
as there is only "one" method there.

3. We do not add no-op default methods to javax.servlet.WriteListener, ReadListener
as all those methods are important.
Developers need to take a look whether they need to override them.
In fact, similar interface in JDK 8, java.nio.channels.CompletionHandler, does not have default methods.

4. For javax.servlet.AsyncListener, we don't want default #onComplete as we may need to clean up resources there.
Similarly, in #onError and #onTimeout. And we leave AsyncListener without default methods for now.

Sending src/main/java/javax/servlet/ServletContextAttributeListener.java
Sending src/main/java/javax/servlet/ServletContextListener.java
Sending src/main/java/javax/servlet/ServletRequestAttributeListener.java
Sending src/main/java/javax/servlet/ServletRequestListener.java
Sending src/main/java/javax/servlet/http/HttpSessionActivationListener.java
Sending src/main/java/javax/servlet/http/HttpSessionAttributeListener.java
Sending src/main/java/javax/servlet/http/HttpSessionBindingListener.java
Sending src/main/java/javax/servlet/http/HttpSessionListener.java
Transmitting file data ........
Committed revision 64156.

Comment by Shing Wai Chan [ 06/Oct/15 ]

Sending status.fm
Transmitting file data .
Committed revision 116.





[SERVLET_SPEC-141] GenericFilter and HttpFilter Created: 23/Sep/15  Updated: 06/Oct/15  Resolved: 06/Oct/15

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

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

Attachments: Zip Archive SERVLET_SPEC-141.zip    

 Description   

https://java.net/projects/servlet-spec/lists/users/archive/2014-10/message/1

The servlet API has a class HttpServlet which extends GenericServlet which
implements Servlet.

For filters, there's only Filter. Implementing this interface directly
incurs the following:

1) There are three methods to implement (init, destroy, doFilter). Most
often I only care about doFilter, so the other two are left empty.
2) doFilter takes ServletRequest and ServletResponse. In 95% of my cases I
need to cast these to HttpServletRequest and HttpServletResponse before I
can do anything useful.
3) If I need access to FilterConfig I need to assign it to a field in init(
FilterConfig)

Compare this to HttpFilter:

1) If I only care about doGet, that's the only method I need to override.
2) All do*-methods take HttpServletRequest, HttpServletResponse parameters,
so I don't need to cast.
3) GenericServlet already has the convenience methods getInitParameter*,
getServletConfig, getServletContext, getServletName and log.

Considering this usability asymmetry between servlets and filters, I
propose we add two new classes to the Servlet API, mostly adopted from it's
servlet cousins:

(Method bodies removed for readability)

public abstract class GenericFilter implements Filter {

@Override
public void destroy()

Unknown macro: { .. }



public String getInitParameter(String name)

public Enumeration<String> getInitParameterNames()

Unknown macro: { .. }



public FilterConfig getFilterConfig()

public ServletContext getServletContext()

Unknown macro: { .. }



public void init(FilterConfig config) throws ServletException

public void init() throws ServletException

Unknown macro: { .. }



public void log(String msg)

public String getFilterName()

Unknown macro: { .. }

}

and:

public abstract class HttpFilter extends GenericFilter {

@Override
public void doFilter(ServletRequest req, ServletResponse res,
FilterChain chain) throws IOException, ServletException {}

protected abstract void doFilter(HttpServletRequest request,
HttpServletResponse response, FilterChain chain) throws IOException,
ServletException ;

}

Adding these two classes will improve the usability of filters, reduce the
amount of boiler plate code, and make filter code more readable.

The cost is adding two new classes. But these classes are symmetric to the
already present HttpServlet / GenericServlet, so the conceptual surface
increase is minimal.

What do the exports think about this? Is this something we could consider
adding in the Servlet 4 time frame?

Thanks,
Eirik Bjørsnøs



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

committed to https://svn.java.net/svn/glassfish~svn/branches/SERVLET_SPEC-141
https://java.net/jira/browse/SERVLET_SPEC-141

SECTION: Modified Files

A src/main/javadoc/doc-files/changed_modified_4_0.png
A src/main/javadoc/doc-files/changed_added_4_0.png
A src/main/javadoc/doc-files/changed_modified_4_0_cursor.cur
A src/main/javadoc/doc-files/changed_added_4_0_cursor.cur
A src/main/javadoc/doc-files/changed_deleted_4_0.png
A src/main/javadoc/doc-files/changed_deleted_4_0_cursor.cur
M src/main/javadoc/javax.servlet-api.css
M pom.xml

  • Create topic branch
    Sending pom.xml
    Adding (bin) src/main/javadoc/doc-files/changed_added_4_0.png
    Adding (bin) src/main/javadoc/doc-files/changed_added_4_0_cursor.cur
    Adding (bin) src/main/javadoc/doc-files/changed_deleted_4_0.png
    Adding (bin) src/main/javadoc/doc-files/changed_deleted_4_0_cursor.cur
    Adding (bin) src/main/javadoc/doc-files/changed_modified_4_0.png
    Adding (bin) src/main/javadoc/doc-files/changed_modified_4_0_cursor.cur
    Sending src/main/javadoc/javax.servlet-api.css
    Transmitting file data ........
    Committed revision 64120.
    dhcp-orl3-2fl-gen-east-10-141-167-3:servlet-SERVLET_SPEC-141 ejburns$ svnhttp

https://svn.java.net/svn/glassfish~svn
dhcp-orl3-2fl-gen-east-10-141-167-3:servlet-SERVLET_SPEC-141 ejburns$ svncom
https://java.net/jira/browse/SERVLET_SPEC-141

SECTION: Modified Files

A src/main/javadoc/doc-files/changed_modified_4_0.png
A src/main/javadoc/doc-files/changed_added_4_0.png
A src/main/javadoc/doc-files/changed_modified_4_0_cursor.cur
A src/main/javadoc/doc-files/changed_added_4_0_cursor.cur
A src/main/javadoc/doc-files/changed_deleted_4_0.png
A src/main/javadoc/doc-files/changed_deleted_4_0_cursor.cur
M src/main/javadoc/javax.servlet-api.css
M pom.xml

  • Create topic branch
Comment by Ed Burns [ 23/Sep/15 ]

Snapshot of API.

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

The above classes are directly parallel to GenericServlet and HttpServlet.
There is a typo in javadoc of GenericFilter#init():
Genericfilter.init --> GenericFilter.init





[SERVLET_SPEC-140] Clarify if the PrintWriter obtained from the ServletResponse is thread safe Created: 21/Sep/15  Updated: 29/Sep/15  Resolved: 29/Sep/15

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

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


 Description   

The Servlet spec (section 2.3.3.4) states that neither the response nor the request are thread-safe and implies that neither are objects obtained from them.

The Javadoc for java.io.Writer implies that all Writers are thread-safe.

Currently, different containers have taken different approaches regarding the thread-safety of the PrintWriter obtained from the ServletResponse. It would help if the expected behaviour was explicitly defined in the spec.



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

Mark filed this issue on Monday. As Mark points out, section 2.3.3.4
states:

"the request and response objects are not thread safe."

Given that the PrintWriter is obtained from the admittedly not thread
safe response, and furthermore that this PrintWriter ultimately writes
to the response, it seems safest to say the following.

Any objects vended from the request or response must be assumed to be
not thread safe. For example, the PrintWriter returned from
ServletResponse.getWriter() and the OutputStream returned from
ServletResponse.getOutputStream() are not thread safe because they
ultimately interact with the response.

Is that sufficient?

Comment by markt_asf [ 24/Sep/15 ]

I like the proposed text. I'd like to propose a variation to try and keep the text consistent with 7.7.1 (the session object is thread safe). Something like:

Unless explicitly stated elsewhere in this specification (e.g. section 7.7.1 for session objects), objects vended from the request or response must be assumed to be not thread safe. This includes, but is not limited to, the PrintWriter returned from ServletResponse.getWriter() and the OutputStream returned from ServletResponse.getOutputStream().





[SERVLET_SPEC-138] Support for HTTP/2 Stream Priority Created: 14/Sep/15  Updated: 18/Sep/15  Resolved: 18/Sep/15

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

Type: Bug Priority: Major
Reporter: Ed Burns Assignee: Shing Wai Chan
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Add a new class Priority
boolean exclusive
int streamId
int weight
Priority dependency
Add method to HttpServletRequest
Priority getPriority()
Add methods to HttpServletResponse
Priority getPriority()
void setPriority(Priority p)



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

Work being done on topic branch https://svn.java.net/svn/glassfish~svn/branches/SERVLET_SPEC-138.

Comment by gregwilkins [ 16/Sep/15 ]

I'm very cautious about this proposal... specially the setPriority part.

Firstly from a HTTP2 perspective the priority is just the clients priority (probably based on a render strategy). This may be (and probably will be) entirely different to service priorities, which are more about achieving maximal throughput for minimal resource allocation, whilst protecting against DOS attack plus providing some degree of fair share between various users.

So at the very least, the getPriority() method should be renamed getClientPriority(). I think that for the most part, this information will be very hard to use unless service resources/scalability are not a concern. Ie. once a request has been dispatched so that something can call getClientPriority() the request, the server has already allocated significant resources to that request process, so that even if a subsequent request (or changed priority of an existing request) is received, the server may still be best to complete the processing of the low priority request with the resources already allocated (as they cannot generally be revoked). However, there are probably some special cases where priority can be used to decide between multiple requests to determine which progresses, so there is no harm exposing this information if it is available.

Note also, that client priority is dynamic and can be changed at any time - so perhaps a listener is needed?

Yet another complexity is that priority is not absolute and is relative only to other streams that may not have an outstanding request on them (in fact browsers have already proposed creating empty streams just so they can express priorities relative to them). There is no matching concept of stream in the Servlet API, so it will be hard to express priorities.

Finally, I don't see how we can set priority. The priority is the client priority and having the server set it to another value will not change the priority. Perhaps it could be used to override any low level priority handling when it comes to determining which bytes to send on which streams???

Comment by Ed Burns [ 16/Sep/15 ]

GW> I'm very cautious about this proposal... specially the setPriority
GW> part.

GW> Firstly from a HTTP2 perspective the priority is just the clients
GW> priority (probably based on a render strategy). This may be (and
GW> probably will be) entirely different to service priorities, which
GW> are more about achieving maximal throughput for minimal resource
GW> allocation, whilst protecting against DOS attack plus providing some
GW> degree of fair share between various users.

For incoming requests, it is certainly the case that the priority is the
client's priority.

GW> So at the very least, the getPriority() method should be renamed
GW> getClientPriority(). I think that for the most part, this
GW> information will be very hard to use unless service
GW> resources/scalability are not a concern.

But isn't the fact that getPriority() is on HttpServletRequest
sufficient indicator that this is the client's priority?

GW> Ie. once a request has been dispatched so that something can call
GW> getClientPriority() the request, the server has already allocated
GW> significant resources to that request process, so that even if a
GW> subsequent request (or changed priority of an existing request) is
GW> received, the server may still be best to complete the processing of
GW> the low priority request with the resources already allocated (as
GW> they cannot generally be revoked). However, there are probably some
GW> special cases where priority can be used to decide between multiple
GW> requests to determine which progresses, so there is no harm exposing
GW> this information if it is available.

Yes, that's our thinking in putting it on HttpServletRequest.

GW> Note also, that client priority is dynamic and can be changed at any
GW> time - so perhaps a listener is needed?

You mean the client sending an UPDATE frame while a request is in the
midst of being processed? That seems like a mess I don't want to get
into.

GW> Yet another complexity is that priority is not absolute and is
GW> relative only to other streams that may not have an outstanding
GW> request on them (in fact browsers have already proposed creating
GW> empty streams just so they can express priorities relative to
GW> them). There is no matching concept of stream in the Servlet API, so
GW> it will be hard to express priorities.

Ahh, I had neglected to file that other issue, I just filed it [1].

GW> Finally, I don't see how we can set priority. The priority is the
GW> client priority and having the server set it to another value will
GW> not change the priority. Perhaps it could be used to override any
GW> low level priority handling when it comes to determining which bytes
GW> to send on which streams???

Ahh, now I get it. Is it the case that the only time the server can
actually set a priority is when they originate a stream? And the only
time they do that is when they do server push, right? So perhaps it's
the case that priority needs to be added to the push API?

Thanks,

Ed

[1] https://java.net/jira/browse/SERVLET_SPEC-139

Comment by gregwilkins [ 16/Sep/15 ]

Maybe I'm convinced about the naming issue of having this on the Request API... but needs to be clear in javadoc.

Adding Request.getStreamId() is certainly good information to expose, but not sure that the model is correct for HTTP2 priorities as it is too request centric. The proposal is:

  • Requests MAY have streamIDs
  • Requests MAY have priority

But in HTTP2 it is:

  • Streams have Priority
  • Streams MAY have requests

ie streams can exist without requests and may be part of the priority tree

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

EB> But isn't the fact that getPriority() is on HttpServletRequest
EB> sufficient indicator that this is the client's priority?

GW> Maybe I'm convinced about the naming issue of having this on the Request API...
GW> but needs to be clear in javadoc.

If that is the case, should we have #getPriority in HttpServletRequest only?

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

The priority is from client side and seems to be too low level to include in Servlet API.
Per discussion in EG, we will mark this issue as "Won't Fix".





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

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

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


 Description   

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



 Comments   
Comment by Shing Wai Chan [ 13/Aug/15 ]

The typo, FilterRegistration and FilterRegistration, have been fixed.

Comment by Shing Wai Chan [ 13/Aug/15 ]

r106 | swchan2 | 2015-02-17 18:22:08 -0800 (Tue, 17 Feb 2015) | 3 lines





[SERVLET_SPEC-124] deny-uncovered-http-methods is missing in Chapter 14 of Servlet spec Created: 18/Feb/15  Updated: 18/Feb/15  Resolved: 18/Feb/15

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

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


 Description   

missing deny-uncovered-http-methods is missing in the
Figure 14-1, Section 14.1, Section 14.4



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

Sending deployment.fm
Sending images/web-app.png
Transmitting file data ..
Committed revision 105.





[SERVLET_SPEC-123] Clarify META-INF/resources in a jar is only for static content, not Java classes Created: 04/Feb/15  Updated: 06/Feb/15  Resolved: 06/Feb/15

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

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

Issue Links:
Related
is related to SERVLET_SPEC-22 Allow static resources to be served f... Resolved

 Description   

GW> Our understanding of META-INF/resources is that it is only for
GW> static content that can be obtained via getResource and that it is
GW> not a place where you can put things like WEB-INF/classes and expect
GW> them to appear on the context classpath.






[SERVLET_SPEC-93] Remove ambiguity in getServerName for IPv6 hosts Created: 11/Jul/14  Updated: 30/Jul/14  Resolved: 30/Jul/14

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

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

Issue Links:
Duplicate
is duplicated by SERVLET_SPEC-97 Host: header and IPv6 addresses Open

 Description   

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.
    */

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



 Comments   
Comment by Ed Burns [ 30/Jul/14 ]

Duplicates SERVLET_SPEC-97





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

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

Type: Improvement Priority: Major
Reporter: Ed Burns Assignee: Shing Wai Chan
Resolution: Invalid Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

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

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



 Comments   
Comment by markt_asf [ 10/Jul/14 ]

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

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

I have looked through the RFC 7230 to RFC 725.
The basic are still used in examples of RFC 7231 'Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content' and RFC 7235 'Hypertext Transfer Protocol (HTTP/1.1): Authentication'.
I do not see any statement in the above RFCs for discouraging the usage of Basic Authentication.

Phil's blog seems to discuss the issue for client asking username and password in general.

Comment by Shing Wai Chan [ 19/Aug/15 ]

Since there is no explicit statement in the HTTP 1.1 RFCs about discouraging Basic Authentication, per discussion with filer, I will close the issue.





[SERVLET_SPEC-80] Wrong Javadoc for ServletContext.getInitParameter() Created: 20/Sep/13  Updated: 20/Sep/13  Resolved: 20/Sep/13

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

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


 Description   

Original bug:
https://bugs.openjdk.java.net/browse/JI-9006641

The original incident is at http://webbugs.us.oracle.com/rt/incidentDisplay?incidentID=2592162

A DESCRIPTION OF THE PROBLEM :
The "Returns" section of getInitParameter() is wrong, it is actually the one of getServerInfo().

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
It should be something along the lines of:

a String containing the value of the named context-wide initialization parameter, or null if the parameter does not exist
ACTUAL -
a String containing at least the servlet container name and version number

URL OF FAULTY DOCUMENTATION :
http://docs.oracle.com/javaee/7/api/javax/servlet/ServletContext.html#getInitParameter%28java.lang.String%29



 Comments   
Comment by Shing Wai Chan [ 20/Sep/13 ]

It is duplicated of https://java.net/jira/browse/SERVLET_SPEC-77





[SERVLET_SPEC-83] ServletContext#getInitParameter with null parameter Created: 09/Oct/13  Updated: 18/Nov/15  Resolved: 13/Aug/15

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

Type: Improvement Priority: Major
Reporter: Shing Wai Chan Assignee: Ed Burns
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 0 minutes
Time Spent: 2 hours, 4 minutes
Original Estimate: Not Specified


 Description   

In the javadoc of ServletContext#getInitParameter, we have

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

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

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



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

I suggest we return the literal string "null" without the quotes. This is what GlassFish currently does.

Comment by Shing Wai Chan [ 12/Aug/15 ]

GlassFish throws NPE in this case.

Comment by markt_asf [ 13/Aug/15 ]

That should be if the name parameter is null for setInitParameter() and setAttribute.

Comment by Ed Burns [ 14/Aug/15 ]

Thanks, fixed.

Comment by pbenedict [ 18/Nov/15 ]

Don't you also want to apply this fix to #getInitParameter in ServletConfig, FilterConfig, GenericFilter, and GenericServlet?





[SERVLET_SPEC-77] Wrong @returns description of javax.servlet.ServletContext.getInitParameter Created: 02/Aug/13  Updated: 05/Aug/13  Resolved: 05/Aug/13

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

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


 Description   

http://docs.oracle.com/javaee/7/api/javax/servlet/ServletContext.html#getInitParameter(java.lang.String)

It says

a String containing at least the servlet container name and version number

as its return value. I think it's just a copy&paste mistake via getServerInfo().

The description should be the same as javax.servlet.ServletConfig#getInitParameter(String).



 Comments   
Comment by Shing Wai Chan [ 05/Aug/13 ]

Sending src/main/java/javax/servlet/ServletContext.java
Transmitting file data .
Committed revision 62445.





[SERVLET_SPEC-72] HttpUpgradeHandler and resource injection Created: 01/May/13  Updated: 14/Aug/15  Resolved: 13/Aug/15

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

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


 Description   

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

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

Which is correct?



 Comments   
Comment by Shing Wai Chan [ 01/May/13 ]

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

Comment by janbartel [ 01/May/13 ]

I don't think that clarifies things, actually.

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

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

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

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

regards
Jan

Comment by Shing Wai Chan [ 01/May/13 ]

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

Comment by Shing Wai Chan [ 13/Aug/15 ]

Sending javaEE.fm
Transmitting file data .
Committed revision 107.





[SERVLET_SPEC-69] NoBodyResponse in HttpServlet.java can have incorrect content length, should override setContentLengthLong(), others Created: 20/Mar/13  Updated: 24/Apr/13  Resolved: 24/Apr/13

Status: Resolved
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: Fixed Votes: 0
Labels: None
Remaining Estimate: 1 hour
Time Spent: Not Specified
Original Estimate: 1 hour


 Description   

(Note: See https://issues.apache.org/bugzilla/show_bug.cgi?id=53454 and https://issues.apache.org/bugzilla/show_bug.cgi?id=54734 for more details.)

The spec JAR contains a file-private class NoBodyResponse in HttpServlet.java that contains a bug in it. This bug has existed for a while but was made worse in the Servlet 3.1 Proposed Final Draft.

NoBodyResponse overrides:

public void setContentLength(int);

However, there are five other ways to change the content length of the response, and NoBodyResponse does not override any of them:

  public void setContentLengthLong(long); // added in Servlet 3.1
public void setHeader(String, String);
public void addHeader(String, String);
public void setIntHeader(String, int);
public void addIntHeader(String, int);

The setContentLengthLong(long) method should be overridden in NoBodyResponse to behave exactly like setContentLength(int). The four header methods should also be overridden, to check if the header name (case-insensitive) is "Content-Length" and behave the same way as setContentLength(int) if it is (Tomcat uses a private void checkHeader(String name) method that is called in of each of the four header methods).



 Comments   
Comment by Nick Williams [ 20/Mar/13 ]

I forgot to mention the negative side effects of not overriding these methods (detailed in Tomcat issue 53454 linked above): If the developer calls setContentLengthLong or any of the header methods to set the content length to some non-zero value in doGet, the HEAD request will still return a Content-Length of 0.

Comment by Shing Wai Chan [ 24/Apr/13 ]

This is an implementation issue and has been fixed in https://java.net/jira/browse/GLASSFISH-20396





[SERVLET_SPEC-49] error-code and error-exception are optional in error-page element Created: 18/Oct/12  Updated: 09/Jan/13  Resolved: 09/Jan/13

Status: Resolved
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: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

See:

https://issues.apache.org/bugzilla/show_bug.cgi?id=52135
http://stackoverflow.com/questions/12854768/jetty-servlet-3-0-and-error-page

It appears the jsr315 spec group may have wanted to make a new feature of having error-pages without defining a code or exception name. Unfortunately there is no text about this in the 3.0 final specification. See section 10.9.2 Error Pages. This is not mentioned.

Nor is there any comment in the web-common.xsd schema.

The only information on this feature can be found on a blog from someone from oracle:
https://blogs.oracle.com/arungupta/entry/totd_136_default_error_page

If this is indeed a new feature that was added in servlet 3.0, this must be documented in the specification.

Jan



 Comments   
Comment by Shing Wai Chan [ 09/Jan/13 ]

We need to update the following:

  • web-common schema
  • section 14.4 No. 15, p.157 in Spec
  • section 10.9.2, p.108 in Spec
Comment by Shing Wai Chan [ 09/Jan/13 ]

The spec is updated as follows:
Sending applications.fm
Sending deployment.fm
Sending status.fm
Transmitting file data ...
Committed revision 64.

Concerning the schema, I have confirmed that it has been updated correctly in Servlet 3.0. We only need to add additional comments there.

Comment by Shing Wai Chan [ 09/Jan/13 ]

fix schemas:
Sending src/main/resources/glassfish/lib/schemas/web-common_3_1.xsd
Transmitting file data .
Committed revision 58247.

Sending javaee7/src/web-common_3_1.xsds
Transmitting file data .
Committed revision 58248.





[SERVLET_SPEC-48] Adding servlet programmatically vs @WebServlet Created: 17/Oct/12  Updated: 02/Nov/12  Resolved: 02/Nov/12

Status: Resolved
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: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

In Section 8.1.1 of Servlet 3.0, we have the following:
If the same servlet class is declared in the deployment descriptor under a different name, a new instance of the servlet MUST be instantiated. If the same servlet class is added to the ServletContext via the programmatic API defined in Section 4.4.1, "Programmatically adding and configuring Servlets" on page 4-31 the values declared via the @WebServlet annotation MUST be ignored and a new instance of the servlet with the name specified MUST be created.

Both sentence should referred to adding the same servlet class with the "different name".
So, the second sentence should be modified as follows:
If the same servlet class is added with the different name to the ServletContext via the programmatic API defined in Section 4.4.1, "Programmatically adding and configuring Servlets" on page 4-31, the attribute values declared via the @WebServlet annotation MUST be ignored and a new instance of the servlet with the name specified MUST be created.



 Comments   
Comment by Shing Wai Chan [ 02/Nov/12 ]

Revisions:
----------
45

Modified Paths:
---------------
trunk/eod-pluggability.fm
trunk/status.fm





[SERVLET_SPEC-43] Clarify behaviour of HttpServletResponse#encodeURL() with relative URLs Created: 28/Jul/12  Updated: 06/Mar/13  Resolved: 06/Mar/13

Status: Resolved
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: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

The Javadoc for HttpServletResponse#encodeURL() states that "The implementation of this method includes the logic to determine whether the session ID needs to be encoded in the URL."

The Javadoc gives one example of a test. Another possible test that may be performed is "Is the URL part of the web application?". If it is not, the session ID does not need to be encoded in the URL.

That highlights the question of how relative URLs should be treated. The options I see are:
a) relative URLs are always assumed to be part of the web application
b) relative URLs are always relative the current HttpServletRequest
c) container specific
d) something else

My current expectation is that b) is the intended behaviour and that it was not explicitly stated since it was viewed as the only possible option. It would be helpful of this expectation could be confirmed or denied and either way if a clarification could be added to the Javadoc for 3.1 onwards (and earlier versions where possible).

Note the same issue exists for encodeRedirectURL()

This question was triggered by https://issues.apache.org/bugzilla/show_bug.cgi?id=53469



 Comments   
Comment by Shing Wai Chan [ 09/Feb/13 ]

Since the #encodeURL string may be used later, we may like to keep it as relative, too.
For #encodeRedirectURL, I expect (b), too.

Comment by markt_asf [ 09/Feb/13 ]

That works for me. If some language can be added that relative URLs passed to encodeURL() and encodeRedirectURL() are relative to the current request that would be great.





[SERVLET_SPEC-42] Clarify wether @WebServletAnnotation can complete a preliminary servlet registration Created: 04/Jul/12  Updated: 25/Feb/13  Resolved: 14/Feb/13

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

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


 Description   

The <servlet> web.xml element was changed to remove the requirement to specify a <servlet-class>. This results in what is referred to as a "preliminary servlet registration". The specification/javadocs describe how the ServletContext.addServlet() methods can be used to complete the registration, but does not mention whether or not a WebServletAnnotation can be used to do so.

Eg
web.xml contains:
<servlet>
<servlet-name>Foo</servlet-name>
</servlet>

FooServlet.java contains:
@WebServlet(urlPatterns =

{"/","/test/*"}

, name="Foo", initParams=

{@WebInitParam(name="fromAnnotation", value="xyz")}

)
public class FooServlet extends HttpServlet

Is the servlet registration for "Foo" updated with classname "FooServlet" after processing the annotation?



 Comments   
Comment by Rajiv Mordani [ 18/Jul/12 ]

Yes the idea is that a descriptor can override any information specified in the annotation (look at the rules for merging in the spec.) So to answer your question as long as metadata-complete is not set - the annotation and descriptor combine to give the effective declaration.

Comment by Rajiv Mordani [ 25/Feb/13 ]

Also in the javadocs for Registration.java it clearly says - "A Registration object whose

{@link #getClassName}

method returns null is considered <i>preliminary". If a servlet is annotated, the getClassName will not return null and hence will not be considered preliminary.





[SERVLET_SPEC-34] Auth constraint that requires a valid user, but does not require any particular role Created: 16/Mar/12  Updated: 01/Mar/13  Resolved: 01/Mar/13

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

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

Tags: security

 Description   

For many applications, the it is desirable to have authentication handled by the container, while authorization must be handled by the application login. In such scenarios, it would be useful to require the a user is logged on, without having to specify roles.

There is precendence for this kind of security from other environments:

Since the last one conflicts with the current spec, maybe something like this would work:

<auth-constraint anyAuthenticatedUserAllowed="true" />
@ServletSecurity(@HttpConstraint(anyAuthenticatedUserAllowed=true))
public class Example4 extends HttpServlet {
}


 Comments   
Comment by Shing Wai Chan [ 09/Jan/13 ]

According to JSR 115 MR2, "*" means all the roles defined for the web app.
It is not any users there.

Comment by elygre [ 09/Jan/13 ]

Shing Wai Chan Yes, that is correct. This issue is an enhancement request for a new auth-constraint that does not require roles, but instead just requires any valid user.

The use case is very common. As show above, the google app-engine deviates from the servlet spec and redefines this aspect of web.xml to support the use case. That should be a strong argument that there is a market requirement.

Comment by Shing Wai Chan [ 10/Jan/13 ]

"*" is for any roles rather than users as defined in JSR 115.
We need to investigate a backward compatible solution.

One way to achieve this is to have the realm to add a universal role to any authenticated users. This is how GlassFish resolve this issue.
You can find more details in
https://blogs.oracle.com/swchan/entry/assign_groups

Comment by elygre [ 10/Jan/13 ]

I totally agree that we need a backward compatible solution. The jira issue does not suggest using the role name "*" at all, but clearly states that this "conflicts with the current spec", and suggests that something else is needed, "maybe the something like this would work":

<auth-constraint anyAuthenticatedUserAllowed="true" />

The GlassFish solutions is interesting. I would hope for a servlet-level solution (which would then be supported by all appservers), but at least it serves to further validate the requirement

Comment by Shing Wai Chan [ 01/Mar/13 ]

A special role "**" is added to achieve this in the spec.
Please see section 13.3 of the Servlet 3.1 PFD for details.

Comment by Shing Wai Chan [ 01/Mar/13 ]

See also section 13.4.1.3 in Servlet 3.1 PFD.





[SERVLET_SPEC-36] Clarify relationship of metadata-complete and ServletContainerInitializers Created: 29/Mar/12  Updated: 14/Aug/12  Resolved: 14/Aug/12

Status: Resolved
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: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Servlet Spec 3.0 does not make clear what relationship exists between metadata-complete setting in web.xml and the discovering and invocation of ServletContainerInitializers.

The stated purpose of ServletContainerInitializers is to allow for pluggable framework initialization, and the given example is initializing the JSP container. This implies that a setting of metadata-complete=true is irrelevant to the finding and calling of ServletContainerInitializers.

If so, even if metata-complete==true for a given webapp, then we are forced to scan every class available to the webapp in the case that a discovered ServletContainerInitializer has a @HandlesTypes annotation - if the HandlesTypes specifies an annotation, then we will scan every class for that annotation, or if HandlesTypes specifies a class, then we need to scan for that class and its descendants. This can take a significant amount of time for a webapp with a large number of jars in WEB-INF/lib.

Please clarify if this is correct, or if metatadata-complete==true means that all ServletContainerInitializers are ignored.



 Comments   
Comment by Shing Wai Chan [ 18/May/12 ]

The metadata-complete and invocation of ServletContainerInitializers are independent.

Comment by markt_asf [ 22/Jun/12 ]

There is one further additional clarification required.

If metadata-complete=true, that implies that any fragment ordering specified is ignored.

However, if the main web.xml specifies an absolute ordering when metadata-complete=true, are all JARs in WEB-INF/lib processed for ServletContainerInitializers or are JARs excluded from the ordering still excluded from the processing for ServletContainerInitializers?

Comment by Rajiv Mordani [ 26/Jul/12 ]

If metadata-complet is true - then the web-fragments (not only the ordering) are ignored. Howerver the jars in WEB-INF/lib will still be processed for ServletContainerInitializers. Ordering does not apply to ServletContainerInitializers.

Comment by Shing Wai Chan [ 27/Jul/12 ]

From p.67 of Servlet 3.0 spec, we have
"The <absolute-ordering> element may contain zero or one <others /> element. The required action for this element is described below. If the <absolute-ordering> element does not contain an <others/> element, any web-fragment not specifically mentioned within <name /> elements MUST be ignored. ... If a discovered ServletContainerInitializer is loaded from an excluded jar, it will be ignored. Excluded jars are not scanned for classes to be handled by any ServletContainerInitializer."

So, excluded jars in absolute-ordering independent of metadata-complete=true will not be scanned for ServletContainerInitializers.

Comment by markt_asf [ 28/Jul/12 ]

<quote>
So, excluded jars in absolute-ordering independent of metadata-complete=true will not be scanned for ServletContainerInitializers.
</quote>

works for me since it provides a way to disable scanning for SCIs.

Comment by Mark Struberg [ 30/Jul/12 ]

Shing, Rajiv could you please point me to the spec paragraph where it's written down that ServletContainerInitializer class scanning must be done regardless of metadata-complete="true"?

Because Section 8.2.1 seems to contradict your statement:

8.2.1: "As before, if the metadata-complete element is set to true in the web.xml descriptor, annotations in the class files and web-fragments bundled in jars will not be processed."
There is no exclusion or "unless stated otherwise" ...

There is a more detailed statement for ServletContainerInitializers in 8.2.2:
"If a discovered ServletContainerInitializer is loaded from an excluded jar, it will be ignored. Excluded jars are not scanned for classes to be handled by any ServletContainerInitializer."

The whole 8.2.4 section also doesn't define any exception.
And section 8.4 "Processing annotations and fragments" seems to underline my interpretation.

To me as uneducated servlet spec reader (though an educated EG member) I read it in summary that ServletContainerInitializers shall get ignored if metatadata-complete="true" is set in WEB-INF/web.xml.

Again: maybe I just didn't search good enough and there is a clear definition in the spec that it should get processed - if so, then please point me to it - thanks!

If not: the rules of the JCP define that once a spec is final then ONLY the released JavaDocs and the spec wording counts - not any 'intent' anymore...

I also do not really understand the goal of this interpretation.
If I set metatdata-complete="true" then I fnnnnn dare don't like any 'implicit' mechanisms. Each EE container brings a ServletContainerInitializer for JSF, JAX-RS, JAX-WS, and tons of others. But what if I like to build something completely different? Some Tapestry or even jruby app? Then I get all the crap activated which is not needed in my case?

I'm also not sure if an empty <absolute-ordering/> would work, as web-fragments are only jars in WEB-INF/lib but ServletContainerInitializer clearly also targets other shared container classpaths as well.

Comment by Shing Wai Chan [ 30/Jul/12 ]

The metadata-complete=true means the completeness of data specified in deployment descriptor.
But it does not mean the annotation will be ignored in the given application.
For instance, CDI annotations will still be scanned and processed.

The ServletContainerInitializer is a service provider specified in META-INF/services, not by annotation. In a ServletContainerInitializer, there may be a @HandlesTypes, which does not have corresponding metadata in deployment descriptor. Since a ServletContainerInitializer and @HandlesTypes are worked together, it should be interpreted whenever a ServletContainerInitializer is loaded.

Comment by Mark Struberg [ 31/Jul/12 ]

Shing, don't get me wrong. The question is not whether you think it should not be scanned by the servlet engine but whether it's written down in the spec. I just found a few paragraphs which all seem to express that absolutely no annotation scanning is done if metadata-complete="true" is set. And there are even a few paragraphs which define this explicitly for ServletContainerInitializer!

Thus I'll ask again: please point me to the paragraphs in the spec which underlines your interpretation. I just could not find it, but I only quickly read through it so I might have overlooked it.

There are 3 possible situations now:

a.) Your 'interpretation' is expressed in a paragraph of the servlet-3.0 spec PDF (or JavaDocs). And this wording is clear that the other paragraphs do not count. Well, then servlet containers must scan of course!

b.) The spec wording is ambiguous and the still to be found paragraph and the few paragraphs I pointed to (expressing the opposite) are expressing contrary facts. In that case you should clarify this in the next spec. Until then any servlet container would be free to implement it as they like.

c.) There is no such paragraph which explicitly expresses that annotations must get scanned even if metadata-complete="true". In that case only this spec wording counts. If you would like to change this behaviour then I suggest you read through the guidelines of how to cope with incompatible changes in Java specs. You are e.g. only allowed to change this in a full release and not in a MR.

I've perfectly understood that the ServletContainerInitializer uses the java.util.ServiceProvider and not web.xml, but please read 8.2.2:
"If a discovered ServletContainerInitializer is loaded from an excluded jar, it will be ignored. Excluded jars are not scanned for classes to be handled by any ServletContainerInitializer."

There is NO room for any other interpretation imo! At least if there is not yet another paragraph which expresses any contrary behaviour.
The problem with java.util.ServiceLoader is that you can easily enable it, but there is NO way to disable it!

And for the CDI class scanning. Of course a CDI container will scan for annotations, but only if a beans.xml is found for that jar - otherwise it won't. It happens that I'm one of the guys writing the CDI spec...

Comment by Shing Wai Chan [ 31/Jul/12 ]

The following is from schema of web.xml:
"The metadata-complete attribute defines whether this deployment descriptor and other related deployment descriptors for this module (e.g., web service descriptors) are complete, or whether the class files available to this module and packaged with this application should be examined for annotations that specify deployment information.
If metadata-complete is set to "true", the deployment tool must ignore any annotations that specify deployment information, which might be present in the class files of the application."

So, the metadata-complete is related to annotations that specify deployment descriptor information. But there is no deployment descriptor for @HandlesTypes in this case.
(CDI is another example that the annotations specifying information not in deployment descriptor.)

While sending my previous comments, I have sent an email to Servlet 3.1 EG about adding a clarification ("independent of metadata-complete") in 8.2.4 as follows:
"In addition to the ServletContainerInitializer we also have an annotation - HandlesTypes. The annotation will be applied on the implementation of ServletContainerInitializer, independent of metadata-complete, to express interest in classes that are either annotated with the classes specified in the value or if a class extends / implements one of those classes anywhere in the classes super types."

Comment by Mark Struberg [ 31/Jul/12 ]

The quote you just posted is another argument for NOT scanning if metadata-complete="true".

Shing, just to make the clear point: CURRENTLY the servlet-3.0 spec DEFINES CLEARLY that metadata-complete="true" DISABLES ANY class scanning!

There are a dozen paragraphs which underline this point of view in the spec + in the JavaDocs + even in the schema for web.xml. And there seems to be NONE which says the opposite.

There is just NOTHING to clarify as the wording is absolutely clear. You could just clarify things which are not or not defined at all or not sufficiently clear defined!

As it seems to stand now (unless someone posts the paragraph which defines the opposite), the Servlet-3.0 specification clearly defines that metadata-complete="true" disables any class-scanning and ServletContainerInitializers wont get picked up neither.

Let's look at this from another side: what are you trying to achieve? What is the reason (use-cases) why you like to have it automatically enabled, even if a user says he doesn't like to get any stuff?

Comment by Mark Struberg [ 31/Jul/12 ]

PS: for servlet-3.1 you should pick up the discussion initiated in the EE-7 umbrella spec about a generic scan.xml which tries to cover the scanning aspects for all the EE parts.

Comment by Shing Wai Chan [ 31/Jul/12 ]

Mark, according to document for web.xml schema mentioned above, metadata-complete is "only" related to "annotations that specify deployment information". It is "not" for "any" annotation. This is not specific to servlet spec. Java EE spec, for instance ejb-jar_3_1.xsd, also defines the metadata-complete this way.

Comment by Mark Struberg [ 31/Jul/12 ]

Yes Shing, I understood your argument. But please allow me to disagree with the underlying subsumption: as the ServletContainerInitializer is a 'metadata pickup mechanism' (it's defined in the servlet spec and used to initialize webapps), and the web.xml is the configuration for all stuff handled by the servlet spec, it imo certainly qualifies as 'servlet metadata' so to speak.

Of course there is no 1:1 analogon between the ServletContainerInitializer and a web.xml tag, but it is kind of a 'bracelet' around various of them.

Please look at servlet-3.0 8.2.4, 8.2.1 and a few other paragraphs. In all those the ServletContainerInitializer is mentioned on exactly the same level as all other servlet-spec 'metadata'. I can see no reason for not applying the same rules defined to the other parts of the spec.

One of my argumentation chain is the following (there are actually quite a few arguments, for paragraphs see above):

1.) a jar is a web fragment. explicit or implicit
2.) if metadata-complete="true" is set in WEB-INF/beans.xml only the web-fragments in <absolute-ordering> count. If there is no <absolute-ordering> then there is no web-fragment enabled.
3.) 8.2.2: "If a discovered ServletContainerInitializer is loaded from an excluded jar, it will be ignored. Excluded jars are not scanned for classes to be handled by any ServletContainerInitializer."

With which of the points don't you agree?

Comment by Shing Wai Chan [ 31/Jul/12 ]

Besides web.xml, there are other metadata in a web application.
Prior to Servlet 3.0, a classpath can be specified in MANIFEST.MF.
In Servlet 3.0, web-fragment.xml can be specified in a given jar.

I see ServletContainerInitializer in 8.2.2 and 8.2.4, but not in 8.2.1.
The included jars, hence excluded jars, specify in <absolute-ordering> is independent of the value of metadata-complete.
In 8.2.2, it describes the behaviors of excluded jars.
In 8.2.4, it is not related to deployment descriptor metadata.

ServletContainerInitializer is a service provider specified in META-INF/services.
And it can be resided in a jar outside a web application.

And in general, the ServletContainerInitializer is for framework like jsp, jsf, etc.
Jsp and Jsf should not be turned off when metadata-complete=true (cf. section 8.3 of Servlet 3.0 spec).

Comment by Mark Struberg [ 31/Jul/12 ]

I'm not sure what your point with the manifest is?

> The included jars, hence excluded jars, specify in <absolute-ordering> is independent of the value of metadata-complete.

8.2.1: "... As before, if the metadata-complete element is set to true in the web.xml descriptor, annotations in the class files and web-fragments bundled in jars will not be processed."

or a bit paraphrased: "... if the metadata-complete element is set to true ... web-fragments bundled in jars will not be processed.".

Which I read as: No annotations, no web-fragments, which mean jars of web-fragments not listed in the web.xml are excluded from processing if metadata-complete="true". Is this interpretation correct? Yes/No?

And now please combine this with the rules specified in 8.2.2:
"Excluded jars are not scanned for annotated servlets, filters or listeners. However, if a servlet, filter or listener from an excluded jar is listed in web.xml or a non-excluded web-fragment.xml, then it's annotations will apply unless otherwise excluded by metadata-complete. ServletContextListeners discovered in TLD files of excluded jars are not able to configure filters and servlets using the programmatic APIs. Any attempt to do so will result in an IllegalStateException. If a discovered ServletContainerInitializer is loaded from an excluded jar, it will be ignored. Excluded jars are not scanned for classes to be handled by any ServletContainerInitializer."

I just mentioned 8.2.4, because it does not mention any exclusions to the general rules defined in 8.2.1.

Comment by Shing Wai Chan [ 31/Jul/12 ]

I mention MANIFEST.MF as another example of metadata.

We may like to clarify the wording of 8.2.1 to be more specific to deployment descriptor related annotations.
If we interpret 8.2.1 as no processing for "all" annotation, then does it means that CDI annotations should not be processed. Of course, this is "not" the case. (And this is also contradict the documents in web.xml schema.)

Also, in our case, we have the annotation, @HandlesTypes. And if we do not process @HandlesTypes (when metadata-complete=true) and still look up the META-INF/services, in this case, ServletContainerInitializer, then the ServletContainerInitializer will not be working properly.

As I mentioned before, we would have a clarification on 8.2.4. And we would like to be more specific about the deployment descriptor related annotations.

Comment by Shing Wai Chan [ 31/Jul/12 ]

This issue is discussed in expert group and the email archive can be found in http://java.net/projects/servlet-spec/lists/users/archive with subject "About SERVLET_SPEC-36".

Comment by Mark Struberg [ 01/Aug/12 ]

> If we interpret 8.2.1 as no processing for "all" annotation, then does it means that CDI annotations should not be processed.
You are mixing apples with eggs. What does the CDI annotations have to do with servlet specific annotations?

The main point here is: if you don't allow a user to disable the SCI somehow, then this might be a major pain in some situations!

In our case it IS already a major pain that SCI automatically start if there is no web.xml. Not only the vastly higher scan times, but e.g. JSF defines that a SCI must be present for automatically starting JSF. In our case this did lead to starting JSF for our resources webapp which contains no JSF at all! It just blew up on servlet-3.0 containers and we had to do crazy things to get rid of it.

I'm perfectly fine if an empty <absolute-ordering/> finally will disable SCI pickup!

Please allow me to ask for another clarification:
What is the lifecycle of the SCI? It's name "Serlvet CONTAINER Initializer" indicates that this only gets scanned 1 time when the container boots. Completely independent of any web application deployed therein.
8.2.4 "An instance of the ServletContainerInitializer is looked up via the jar services API by the container at container / application startup time"

It also defines when the onStartup method gets called, but I have not yet understood if there is 1 SCI instance per webapp and SCI-Class or if the container startup creates a singleton for the whole container and all webapps invoke the onStartup to the same instance? Is this mentioned somewhere? This has a major impact about how to write the SCIs. Please also think about having 2 webapps containing jsf-impl.jar in their WEB-INF/lib (so the same JsfSCI but in 2 different isolated classloaders) vs having the jsf-impl.jar in a container lib dir.

Comment by Shing Wai Chan [ 14/Aug/12 ]

The metadata-completed is clarified as mentioned above. For ServletContainerInitializer, an instance will be created at each application startup time.

Sending eod-pluggability.fm
Sending overview.fm
Sending status.fm
Transmitting file data ...
Committed revision 41.





[SERVLET_SPEC-35] Clarification on section 4.4 Servlet Context Configuration Methods Created: 24/Mar/12  Updated: 05/Mar/13  Resolved: 05/Mar/13

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

Type: Improvement Priority: Major
Reporter: Christian Ludt Assignee: Rajiv Mordani
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

If the ServletContext passed to the ServletContextListener's
contextInitialized method was neither declared in web.xml or
webfragment.xml nor annotated with @WebListener then an
UnsupportedOperationException MUST be thrown for all the
methods defined for programmatic configuration of servlets,
filters and listeners.

This sentence is misleading; leaving out the relative clause gives:

If the ServletContext was neither declared in web.xml or webfragment.xml nor annotated with @WebListener [...]

The ServletContext is created by the Servlet container and can neither be declared in web.xml or webfragment nor annotated, but the ServletListenerContext can be. So, if

neither declared in web.xml or webfragment.xml nor annotated with @WebListener

refers to ServletContextListener, please make that clear.

Still, I don't understand, why and when an UnsupportedOperationException must be thrown. Must it be thrown when that ServletContextListener is added via ServletContext#addListener? What sense would it make to throw an exception here? If that listener had been declared in web.xml or webfragment.xml or annotated, there would be no need to add it programmatically in the first place.



 Comments   
Comment by janbartel [ 01/Mar/13 ]

Can we please have some clarification on what this wording means prior to Public Final release?

There was never any answer to Mark's question on the email thread about this issue "About SERVLET_SPEC_35" on the mailing list.

thanks
Jan

Comment by Rajiv Mordani [ 04/Mar/13 ]

Yes the reference is to the ServletContextListener and not the ServletContext.

The case I believe we were trying to address with this in Servlet 3.0 time was that when ServletContextListener was created from a TLD, then those listeners should not be allowed to use the programmatic APIs.

Comment by Rajiv Mordani [ 05/Mar/13 ]

Yes in fact I did go back and look at the servlet 3.0 archives and we want to disallow the ServletContextListeners that were declared in TLDs. I have clarified the fact that it is the listener and not the ServletContext that needs to be declared and am marking this issue as fixed.





[SERVLET_SPEC-53] Clarify expected behaviour if multiple servlets are mapped to the same URL pattern Created: 08/Jan/13  Updated: 09/Jan/13  Resolved: 09/Jan/13

Status: Resolved
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: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

I have checked through the latest specification draft and can;t find any language covering this.

If I map both servletA and servletB to /foo in web.xml what happens? Clearly, they can't both execute.

My expectation at this point is that a web application with multiple servlets mapped to exactly the same url pattern should fail to start.

Please could we add some clarifying language to the Servlet 3.1 spec.



 Comments   
Comment by Shing Wai Chan [ 09/Jan/13 ]

Sending requestmappings.fm
Transmitting file data .
Committed revision 63.





[SERVLET_SPEC-51] Clarification is needed for ServletContext.addFilter(...) and ServletContext.addServlet(...) Created: 03/Jan/13  Updated: 08/Jan/13  Resolved: 08/Jan/13

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

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


 Description   

Hi,

Javadoc for ServletContext.addFilter(...)/ServletContext.addServlet(...) does not specify what should be the behaviour when filterName/servletName is NULL.

Would you specify whether filterName/servletName is mandatory or optional and what should be the behaviour of these methods.

From my point of view filterName/servletName should be mandatory and IllegalArgumentException should be thrown when filterName/servletName is NULL.

Thanks in advance
Violeta Georgieva



 Comments   
Comment by BGehrels [ 03/Jan/13 ]

My feelings about this issue are a little bit ambivalent.

On the one hand side the servlet and filter names are used in other parts of the ServletContext API, for example in getServletRegistrations(). If one would make filterName/servletName optional, then the behaviour for those methods would be unclear.

On the other hand, there is no need for a name, if you configure your whole WebApp using the addServlet/addFilter-Mechanism: The filterName is mainly usefull to reference your servlet from other locations. When using the Java API, javax.servlet.ServletRegistration.Dynamic/javax.servlet.FilterRegistration.Dynamic are used to reference your Servlet/Filter registrations. So, for those users, having to generate a unique name for each servlet and each filter is useless and may also be non-trivial when you are writing generic frameworks (for example).

From my point of view, having a way to define anonymous filters/servlets would be a very nice thing to have. One (ugly) way to allow this would be, to allow null values hier. A better way would probably be to add

public ServletRegistration.Dynamic addServlet(String className);
public ServletRegistration.Dynamic addServlet(Servlet servlet);
public ServletRegistration.Dynamic addServlet(Class <? extends Servlet> servletClass);
public FilterRegistration.Dynamic addFilter(String className);
public FilterRegistration.Dynamic addFilter(Filter filter);
public FilterRegistration.Dynamic addFilter(Class <? extends Filter> filterClass);

to the ServletContext interface.

Comment by markt_asf [ 03/Jan/13 ]

ServletContext#getServletRegistrations() and ServletContext#getFilterRegistrations() can't work if there are multiple anonymous Servlets or multiple anonymous Filters since while Map implementations may support null keys, they don't (and can't) support multiple null keys in a single map since keys have to be unique.

Given the above and the wording of the Javadoc for ServletContext#addFilter() and ServletContext#addServlet() I think there is a strong argument that the names are required and that the Servlet specification should be clarified make this clear. I'd be fine with adding a requirement for a IAE if a null name is provided.

Comment by Shing Wai Chan [ 03/Jan/13 ]

I agree that we should throw IllegalArgumentException for ServletContext#addFilter and ServletContext#addServlet if null name is used.
In no. 7 of section 14.4 of the spec, we have:
"The element content of filter-name element must not be empty."

In this case, I think we need to throw IllegalArgumentException if the name is "".

Comment by violetagg [ 04/Jan/13 ]

Hi,

In this case, I think we need to throw IllegalArgumentException if the name is "".

If we start returning IAE when the filterName/servetName is "" then we need clarification also for WebFilter and WebServlet.
In the javadoc "" is default for filterName/servletName.

javax.servlet.annotation.WebFilter

filterName

public abstract java.lang.String filterName
The name of the filter
Default:
""

javax.servlet.annotation.WebServlet

name

public abstract java.lang.String name
The name of the servlet
Default:
""

We can use the class name of the filter/servlet as default instead of "".
What do you think?

Thanks
Violeta

Comment by Shing Wai Chan [ 04/Jan/13 ]

For @WebServlet, we have
"The default name of the Servlet if not specified is the fully qualified class name."
Similarly for @WebFilter.
So the name is "fully qualified class name" in this case.

Comment by Shing Wai Chan [ 08/Jan/13 ]

The fix has been to javadoc of ServletContext.java
svn 57969





[SERVLET_SPEC-57] Add getFileName() method to javax.servlet.http.Part Created: 18/Feb/13  Updated: 01/Mar/13  Resolved: 01/Mar/13

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

All


Tags: HttpServletRequest, Part, file_upload, filename

 Description   

The javax.servlet.http.Part interface lacks a method for retrieving the file name of a part. Most request parts have file names, typically provided by the client's browser as the name of the file on the client's file system when the file is uploaded through the form submission. Currently, consumers of Part must create their own method to extract the file name:

public static String getFileName(Part filePart)
{
    String header = filePart.getHeader("content-disposition");
    for(String headerPart : header.split(";"))
    {
        if(headerPart.trim().startsWith("filename"))
        {
            return headerPart.substring(headerPart.indexOf('=') + 1).trim()
                             .replace("\"", "");
        }
    }
    return null;
}

Tomcat, as an example, already has a method to extract the file name in its Part implementation, but since it is not exposed via the public Part interface developers cannot use it without limiting the portability of their applications. It's possible other containers already do something similar.

The suggested getFileName() method should:

  • Locate the Content-Disposition header from the Part. If no such header exists, return null.
  • Extract the filename attribute from the Content-Disposition header and return its value trimmed.
  • If no filename attribute exists or the filename attribute value is null, return null.
  • Not throw any exceptions.

Estimate 5 minutes to add the method to the interface and < 2 hours to add relevant documentation regarding the method to the spec.



 Comments   
Comment by Nick Williams [ 18/Feb/13 ]

Note that the sample code submitted does not follow the second part of rule 1, "If no such header exists, return null." A more stable implementation would be:

public static String getFileName(Part filePart)
{
    String header = filePart.getHeader("content-disposition");
    if(header == null)
        return null;
    for(String headerPart : header.split(";"))
    {
        if(headerPart.trim().startsWith("filename"))
        {
            return headerPart.substring(headerPart.indexOf('=') + 1).trim()
                             .replace("\"", "");
        }
    }
    return null;
}

Of course, this is merely a sample implementation, and container developers are free to implement the spec in their own way.

Comment by carojkov [ 18/Feb/13 ]

I'd like to propose a method name that clearly states that this is a file name specified by the client. e.g. getClientFileName(). getRequestedFileName() or getSubmittedFileName(). This should help avoid confusion if/when it's decided if adding another get*File() method to the Part is needed. i.e. getFile() returning File after a call to Part#write(String) method.

Comment by Nick Williams [ 18/Feb/13 ]

I agree. I prefer getSubmittedFileName(). Seems the most applicable, as that's exactly what it is: nothing more or less than the submitted file name.

Comment by markt_asf [ 18/Feb/13 ]

+1

Comment by Nick Williams [ 20/Feb/13 ]

By the way, Mark, if this gets accepted for 3.1 I'll implement it in Tomcat. Should just be a matter of adding the method to the interface and then implementing the method in ApplicationPart to wrap ApplicationPart#getFilename().

Comment by Shing Wai Chan [ 01/Mar/13 ]

Add a method Part#getSubmittedFileName

Sending src/main/java/javax/servlet/http/Part.java
Transmitting file data .
Committed revision 59926.





[SERVLET_SPEC-56] clarify effect of disabling the use of url rewriting for session tracking on HttpServletResponse.encodeURL() and HttpServletResponse.encodeRedirectURL() Created: 14/Feb/13  Updated: 05/Mar/13  Resolved: 05/Mar/13

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

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


 Description   

when url rewriting has been disabled as a session tracking mechanism
HttpServletResponse.encodeURL() and HttpServletResponse.encodeRedirectURL() must
not encode the session identifier.



 Comments   
Comment by Shing Wai Chan [ 05/Mar/13 ]

Update javadoc for HttpServletResponse#encodeRedirectURL
fix in svn commit 59928





[SERVLET_SPEC-55] recommend that login from specify autocomplete=off Created: 14/Feb/13  Updated: 05/Mar/13  Resolved: 05/Mar/13

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

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


 Description   

submitting recommendation from Jeff Williams



 Comments   
Comment by Shing Wai Chan [ 05/Mar/13 ]

Sending security.fm
Sending status.fm
Transmitting file data ..
Committed revision 80.





[SERVLET_SPEC-54] Javadoc inconsistent for HttpServletRequest#changeSessionId() Created: 13/Feb/13  Updated: 14/Feb/13  Resolved: 14/Feb/13

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

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


 Description   

The Javadoc for the above method has inconsistent statements about the return value.

<quote>
String changeSessionId()

Change the session id of the current session associated with this request and return the new session id.

Returns: the original session id
</quote>

I believe that the return value should be the new ID



 Comments   
Comment by Shing Wai Chan [ 14/Feb/13 ]

Sending src/main/java/javax/servlet/http/HttpServletRequest.java
Transmitting file data .
Committed revision 59507.





[SERVLET_SPEC-64] Wording of section 8.2.4 Shared libraries/runtimes pluggability is unclear or incorrect Created: 01/Mar/13  Updated: 12/Mar/13  Resolved: 04/Mar/13

Status: Resolved
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: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

From the 2nd Public Draft:

Page 89/90:
"In addition to the ServletContainerInitializer we also have an annotation -
HandlesTypes. The HandlesTypes annotation on the implementation of the
ServletContainerInitializer is used to express interest in classes that may
have anotations (type, method or field level annotations) specified in the value of the
HandlesTypes or if it extends / implements one those classes anywhere in the
class' super types. The HandlesTypes annotation is applied irrespective of the
setting of metadata-complete. The container uses the HandlesTypes annotation
to determine when to invoke the initializer's onStartup method."

Having or not having a @HandlesTypes annotation does not influence when the onStartup method is called at all AFAICT - later on the spec says that the the onStartup method is always called when the application is starting up.

"When examining the classes of an application to see if they match any of the criteria specified by the
HandlesTypes annotation of a ServletContainerInitializer, the container
may run into class loading problems if one or more of the application's optional JAR
files are missing. Since the container is not in a position to decide whether these
types of class loading failures will prevent the application from working correctly, it
must ignore them, while at the same time providing a configuration option that
would log them."

This sentence doesn't fit very well with the preceding one, which is talking about when the onStartup method is called. Mention of potential problems in loading the classes of the HandlesTypes, and a requirement for logging should be in a separate paragraph.

Page 80:
"The onStartup method of the ServletContainerInitializer will be invoked
when the application is coming up before any of the listener's events are fired."

Which listener are we talking about here? A listener has not been previously mentioned in this section at all. Is it supposed to say "any of the ServletContextListener events are fired" ????

Page 80:
"The ServletContainerInitializer's onStartup method get's a Set of Classes
that either extend / implement the classes that the initializer expressed interest in or
if it is annotated with any of the classes specified via the @HandlesTypes
annotation."

Should this be: " ... onStartup method gets called with a Set of classes ..."? Or even better " ... onStartup method is called with a Set of classes ..."

IMHO section 8.2.4 does not flow very cleanly and could do with a rewrite.



 Comments   
Comment by janbartel [ 01/Mar/13 ]

The above comments apply to the just-released Public Final Draft.

Also, there is a typo on Page 80, "anotation" should be "annotation".

Jan

Comment by Shing Wai Chan [ 04/Mar/13 ]

Sending eod-pluggability.fm
Transmitting file data .
Committed revision 77.

I have fixed issues described above, except the following:
"The onStartup method of the ServletContainerInitializer will be invoked
when the application is coming up before any of the listener's events are fired."

Since ServletContextListener events are fired before any other servlet events, the above statement is correct. There is no need to change in the spec in this case.

Comment by janbartel [ 12/Mar/13 ]

According to your last comment, then the current English of that sentence is not correct.

The sentence says:
"... before any of the listener's events are fired"

The apostrophe is the possessive form of a singular noun - ie it is talking about 1 specific listener.

Instead, the sentence should refer to all servlet listeners, eg:

"... before any of the servlet listener events are fired"

Jan





[SERVLET_SPEC-8] Clarification on run-as for servlet method Created: 31/Aug/11  Updated: 10/Jan/12  Resolved: 10/Jan/12

Status: Resolved
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: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

I have discussed with Ronald Monzillo about the run-as in servlet.
I try to summarize his comments as follows:

a) In "A.8 Changes Since Servlet 2.3", it states

Clarification: "run-as" identity must apply to all calls from a servlet including init() and destroy() (12.7)

There is no such clarification in the section 12.7 or in the security chapter, so the clarification may have been lost, but the appendix clearly notes the intent, and thus he thinks it is required that a specified run-as identity be in effect during init() and destroy().

b) Note that section 15.3.1 Propagation of Security Identity in EJB Calls, requires that propagation occur whenever an ejb is called by a servlet (without consideration of the Servlet method form which the ejb call is made). That may be going too far, but it would at least support that run-as should be honored within init(); where it is has become common practice to invoke ejbs, and where (unlike the case of calls to ejbs from servlet context listeners), there is a mapping to a specific servlet on which to look for a run-as specification.

I think we should only propagate the security identity when Servlet#init, Servlet#destroy and Servlet#service are called.
(So, there will be no security identity propagation for Servlet#getServletConfig, Servlet#getServletInfo.)



 Comments   
Comment by Shing Wai Chan [ 05/Jan/12 ]

I have further discussion with Ron about this.
We would like clarify the spec from:
"When it is specified, the container must propagate the security identity for any call from a servlet to the EJB layer in terms of the security role name defined in the run-as element. "

to

"When a run-as role is specified for a Servlet, the Servlet container must propagate a principal mapped to the role as the security identity in any call from the Servlet
to an EJB, including calls originating from the Servlet's Servlet#init and Servlet#destroy methods."

In other words, run-as apply to all Servlet's methods when it is invoked by the container.

Comment by Shing Wai Chan [ 10/Jan/12 ]

Sending javaEE.fm
Transmitting file data .
Committed revision 4.





[SERVLET_SPEC-6] Undefined behaviour for AsyncContext#getRequest() and getResponse() after complete()/dispatch() Created: 25/Aug/11  Updated: 11/Feb/13  Resolved: 11/Feb/13

Status: Resolved
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: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

The specification is unclear on what should happen here. Clearly, it isn't going to work but how it fails and when it fails is undefined.

My preference is for declaring that those methods throw IllegalStateException in those circumstances.



 Comments   
Comment by gregwilkins [ 13/Sep/11 ]

I believe the request/response pair should be valid and not recycled until the lifecycle has completed - either with a call to onError or onComplete.

So During those calls, getRequest and getResponse should still return the appropriate object. The use case for this might be to retrieve an attribute from the request or to look at isCommitted or getStatus methods of the request to see what the response was going to be if it had not errored.

Comment by markt_asf [ 18/Sep/11 ]

I'd be fine with that approach. The question remains, what happens after the lifecycle has completed. My preference is still an ISE in that case.

Comment by Shing Wai Chan [ 07/Jan/12 ]

According to javadoc of AsyncContext, when there is async timeout, the
following may be invoked:
a. invoke AsyncListener#onTimeout
b. AsyncContext#complete, AsyncListener#onComplete
c. AsyncContext#dispatch

One should throw IllegalStateException for AsyncContext#getRequest() / getResponse()
if AsyncContext#complete or AsyncContext#dispatch are called.
This will solve the following timeout scenario, too.

Comment by Shing Wai Chan [ 10/Jan/12 ]

Sending src/main/java/javax/servlet/AsyncContext.java
Transmitting file data .
Committed revision 51990.

Sending servletobjects.fm
Sending status.fm
Transmitting file data ..
Committed revision 5.

Comment by gregwilkins [ 30/Jan/12 ]

Because the servlet specification allows (even encourages) object reuse/recycling, it is impossible to require a ISE to be thrown after the lifecycle completes. By definition of recycle, the object has been recycled and is now carrying the state of another request in another lifecycle, and it may well be in a state where such a call is applicable.

All we can say is that after a call to onComplete has returned, then the results of all calls to the AsyncContext API via an existing reference are undefined.

Now given current garbage collectors, it may no longer be good idea not to encourage such object reuse - but many containers already do so, thus it would be a big break to change that.

Comment by Shing Wai Chan [ 30/Jan/12 ]

Need further investigation on request issuee.

Comment by markt_asf [ 30/Jan/12 ]

It should be possible to use a thin, "throw away" wrapper around the AsyncContext that tracked state and threw the Exception leaving the underlying AsyncContext implementation to be safely recycled. Whether this complexity is worth the benefit of changing behaviour from "undertermined" to "throws ISE" is TBD.

My own view is that the complexity is worth the benefit. These sorts of re-use bugs can be really tricky to track down and this change would help considerably.

Comment by gregwilkins [ 31/Jan/12 ]

markt_asf,

I agree that the benefits of reusing objects are probably at best marginal now. A think wrapper may help, but it is probably just as much work to implement as removing the recycling of objects.

For Jetty we definitely plan to evaluate if our current recycling of request,response,asyncContext are still worth it - but it is not a change that we can make lightly.

Also, the state of the art with garbage collection may swing the other way someday, and recycling objects may come back in vogue. Thus I think because the spec originally allowed/encouraged recycling, then it should not change to prohibit recycling - even if containers move away from doing so.

Perhaps we can go for some verbage along the the lines of - all method calls on the AsyncContext are undefined after a call to onComplete. However implementations are encouraged to throw ISE if at all possible.

Comment by Shing Wai Chan [ 02/Feb/12 ]

After timeout or commit, we would like to clarify the use of those previously acquired request or response objects are undefined.
The question is AysncContext.getRequest()/getResponse().
I prefer to have a deterministic behavior here.
As mentioned by Mark, this is feasible in the implementation, I would prefer to throw ISE in this case.

Comment by Rajiv Mordani [ 02/Nov/12 ]

@Greg - I generally don't like to keep things undefined in the spec. I think we should say that an ISE is thrown. It may introduce some complexity for implementations but there are a handful of these . I agree with Mark that these the re-use bugs can be really tricky and hence from the developers point of view it will be very clear to define in the spec that we throw an ISE and require all containers to implement it that way rather than "encourage" container vendors to throw the ISE.

Comment by rstoyanchev [ 05/Nov/12 ]

After timeout or commit, we would like to clarify the use of those previously acquired request or response objects are undefined.

As discussed above, this should not be done after a timeout but only after the lifecycle has completed - i.e. with a call to onError or onComplete. The subject of this issue should be corrected to reflect that as well.

Comment by gregwilkins [ 12/Nov/12 ]

@Rajiv It think we need to be consistent in the specification. If we say that AsyncContext objects throw ISE if used after the request lifecycle is complete, then I think we also need to do the same for the request and response instances themselves. I think it is too confusing to have some objects be reusable and others not.

Besides if AsyncContext.getRequest() throws an ISE, but Request itself is not usable after the completion of the request life cycle, then we have a race condition as an async thread might call getRequest() a nano second before the end of the request life cycle and then perform illegal operations on the request object it got in return.

So either we have to explicitly prohibit all recycling of objects and say that request/response/contexts are all invalid after the completion; OR we continue as we are saying that it is the applications responsibility to not call methods on any of these objects after the lifecycle has completed.

I do not think a half way house of some objects being recyclable while other are not is viable nor easy to understand.

If this was a green field spec, I think that requiring fresh objects on every cycle would be best. But as we have lots of existing code, then I now favour the status quo and that we continue to allow recycling of these objects.

Comment by markt_asf [ 12/Nov/12 ]

Bugs triggered by retaining references to the Request/Response objects are usually more obvious than those involving with AsycnContext. The multi-threaded nature of async adds complexity that does make it easier to get things wrong - hence my focus on AsycnContext.

I'm not against expanding this change to encompass Request/Response and Greg's consistency argument is a valid one but I would also be happy with just changing AsyncContext. I don't think the status quo is a reasonable option.

Comment by markt_asf [ 12/Nov/12 ]

Update title

Comment by Rajiv Mordani [ 12/Dec/12 ]

I'd like to close out on this issue one way or another. Let me start a thread on the EG to make sure that everyone is in fact tracking the issue on issue tracker and see what their opinions are.

Comment by Shing Wai Chan [ 11/Feb/13 ]

Per discussion in expert group discussion, 12/11/12, 1/9/13, 2/4/13, ISE will be thrown in this case.





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

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

Type: Bug Priority: Major
Reporter: Ed Burns Assignee: Ed Burns
Resolution: Fixed 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 ServletException 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-118] Replace and deprecate ServletRequest.getParameter for HttpServletRequest Created: 04/Dec/14  Updated: 20/Jan/17  Resolved: 20/Jan/17

Status: Resolved
Project: servlet-spec
Component/s: Filter/Servlet
Affects Version/s: None
Fix Version/s: None

Type: Improvement Priority: Major
Reporter: jgigov Assignee: Unassigned
Resolution: Works as designed 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-165] Refresh delivery plan for eventual release to Servlet EG Created: 17/Jan/17  Updated: 23/Jan/17  Resolved: 23/Jan/17

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

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

Sprint: MS 2 Sprint 1

 Comments   
Comment by Ed Burns [ 23/Jan/17 ]

JCP milestones approved by Shing-wai.





[SERVLET_SPEC-12] Clarify the path prefix mapping in Section 12.1 Created: 21/Sep/11  Updated: 23/Jan/17  Resolved: 23/Jan/17

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

Type: Improvement Priority: Major
Reporter: Santiago Pericas-Geertsen Assignee: Unassigned
Resolution: Won't Fix 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-75] Multipart part without filename must make part contents available as a string in parameters Created: 11/Jun/13  Updated: 23/Jan/17  Resolved: 23/Jan/17

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

Type: Bug Priority: Major
Reporter: janbartel Assignee: Unassigned
Resolution: Works as designed 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-139] Add int getStreamId() to HttpServletRequest and HttpServletResponse. Created: 16/Sep/15  Updated: 23/Jan/17  Resolved: 23/Jan/17

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

Type: Bug Priority: Major
Reporter: Ed Burns Assignee: Unassigned
Resolution: Won't Fix 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-132] WebSocket and Servlet mappings clarification Created: 07/May/15  Updated: 23/Jan/17  Resolved: 23/Jan/17

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

Type: Bug Priority: Major
Reporter: mmulholl Assignee: Unassigned
Resolution: Works as designed 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-167] Review unresolved issues Created: 23/Jan/17  Updated: 23/Jan/17  Resolved: 23/Jan/17

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

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

Sprint: MS 2 Sprint 2

 Description   

Review unresolved issues as listed in this JIRA query

https://java.net/jira/issues/?jql=project%20%3D%20SERVLET_SPEC%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20component%20ASC%2C%20key%20ASC%2C%20priority%20DESC

Ask yourself some basic questions for each?

  • Has this been fixed already?
  • Can this be closed as "Works as Designed"?
  • Is this one well specified enough to just do the spec and impl work right now?
  • Has there been any work on this during the 4.0 cycle?
  • Are any of the Expert Group members particularly keen on seeing this one resolved?
  • If it has the FUTURE_RELEASE tag, should we attempt it in 4.0?


 Comments   
Comment by Ed Burns [ 23/Jan/17 ]

These two components have a disproportionately large number of hard issues: Security, IO.





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

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

Type: Bug Priority: Major
Reporter: gregwilkins Assignee: Ed Burns
Resolution: Won't Fix Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Sprint: MS 2 Sprint 2

 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.



 Comments   
Comment by Ed Burns [ 23/Jan/17 ]

Asked Java EE Architecture about permissibility of this change.

Comment by Ed Burns [ 24/Jan/17 ]

After consulting with EE arch and Shing-wai, marking this WONTFIX as the breakage in backward compatibility is not worth the improvement in correctness in this case.





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

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

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

Issue Links:
Related
is related to SERVLET_SPEC-154 Consider requiring context-roots to b... Open

 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.



 Comments   
Comment by Ed Burns [ 07/Feb/17 ]

Upon closer inspection of this issue, I see that there is no text in the Servlet spec PDF, the JavaDoc, or the Servlet defined XSDs that defines the context root. The only thing in the XSD is the application_7.xsd, which defines how one writes an application.xml for an EAR. In there, we have a context-root, like this:

  <module>
        <web>
            <web-uri>myweb.war</web-uri>
            <context-root>MyWeb</context-root>
        </web>
    </module>

That context-root is constrained to be a javaee:string, which is defined as

  <xsd:complexType name="string">
    <xsd:annotation>
      <xsd:documentation>

        This is a special string datatype that is defined by Java EE as
        a base type for defining collapsed strings. When schemas
        require trailing/leading space elimination as well as
        collapsing the existing whitespace, this base type may be
        used.
        
      </xsd:documentation>
    </xsd:annotation>
    <xsd:simpleContent>
      <xsd:extension base="xsd:token">
        <xsd:attribute name="id"
                       type="xsd:ID"/>
      </xsd:extension>
    </xsd:simpleContent>
  </xsd:complexType>

According to <http://www.datypic.com/sc/xsd/t-xsd_ID.html>, "The type xsd:ID is used for an attribute that uniquely identifies an element in an XML document. An xsd:ID value must be an NCName. This means that it must start with a letter or underscore, and can only contain letters, digits, underscores, hyphens, and periods."

Comment by Ed Burns [ 07/Feb/17 ]

This seems to be sufficiently constrained based on what is standardized.





[SERVLET_SPEC-89] Need clarification /enhancement to <distributable/> Created: 09/Jun/14  Updated: 09/Feb/17  Resolved: 24/Jan/17

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

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

Sprint: MS 2 Sprint 2

 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.

Comment by Shing Wai Chan [ 23/Jan/17 ]

I agree with Mark on the comments on the "as well". I have updated the spec.

Sending eod-pluggability.fm
Sending status.fm
Transmitting file data ..done
Committing transaction...
Committed revision 125.





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

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

Type: Bug Priority: Major
Reporter: Nick Williams Assignee: Shing Wai Chan
Resolution: Fixed Votes: 4
Labels: None
Remaining Estimate: 1 hour
Time Spent: Not Specified
Original Estimate: 1 hour

Tags: servlet-context, servlet_4_0, session-timeout, sessions
Sprint: MS 3 Sprint 1

 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.

Comment by janbartel [ 24/Jan/17 ]

It has always been possible to change the timeout on an individual session using HttpSession.setMaxInactiveInterval(int sec). Please provide a description of the behaviour in the following cases:

1. are there any restrictions on when or from where this method can be called?
2. will the new method use time unit of minutes or seconds?
3. does the new method affect existing sessions or only sessions created after this method is called?
4. if it affects existing sessions, should it override a value previously established by a call to HttpSession.setMaxInactiveInterval (int sec)?
5. if it affects existing sessions this will be chaotic for distributed sessions: the node on which this call is made may not have any of the existing sessions local to it; if this call was made simultaneously on multiple nodes with different values the results would be non-deterministic.

Comment by Arend v. Reinersdorff [ 25/Jan/17 ]

@janbartel My take on this is the following:

  1. The new API should strictly be a replacement for the session-timeout element in web.xml. All extensions to this like changing the timeout of existing sessions should be separate issues.
  2. The new API should behave like the session-timeout element in web.xml as much as possible, eg accept the same values.
  3. The new API should behave like other methods on ServletContext which are used during initialization, eg throw IllegalStateException if they are called after initialization

Which would answer your questions as follows:

  1. The new method has the same restrictions as other methods on ServletContext which are used during initialization, eg setSessionTrackingModes() or addServet()
    • IllegalStateException - if this ServletContext has already been initialized
    • UnsupportedOperationException - if this ServletContext was passed to the ServletContextListener.contextInitialized(javax.servlet.ServletContextEvent) method of a ServletContextListener that was neither declared in web.xml or web-fragment.xml, nor annotated with WebListener
  2. The new method will use time unit minutes, same as the session-timeout in web.xml.
    • As with the session-timeout in web.xml a value of 0 or less means that sessions will never time out.
  3. The new method does not affect existing sessions, same as the session-timeout element in web.xml
    • This also avoids the problems 4. and 5. that you pointed out.
  4. Existing sessions are not affected, see 3.
  5. Existing sessions are not affected, see 3.

See also:

  • Servlet 3.1 specification page 182, chapter 14.4 Deployment Descriptor Diagram, 12. session-config

    The sub-element session-timeout defines the default session time out interval
    for all sessions created in this Web application. The specified time out must be
    expressed in a whole number of minutes. If the time out is 0 or less, the container
    ensures the default behavior of sessions is never to time out. If this element is not
    specified, the container must set its default time out period.

  • ServletContext.setSessionTrackingModes()

    Throws:
    IllegalStateException - if this ServletContext has already been initialized
    UnsupportedOperationException - if this ServletContext was passed to the ServletContextListener.contextInitialized(javax.servlet.ServletContextEvent) method of a ServletContextListener that was neither declared in web.xml or web-fragment.xml, nor annotated with WebListener

Comment by Shing Wai Chan [ 06/Feb/17 ]

Per discussion with EG, we will only add get/set SessionTimeout in ServletContext.

Revisions:
----------
64446





[SERVLET_SPEC-155] Clarification on getDefaultSessionTrackingModes and getEffectiveSessionTrackingModes Created: 31/Mar/16  Updated: 09/Feb/17  Resolved: 24/Jan/17

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

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

Sprint: MS 2 Sprint 2

 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.

Comment by Shing Wai Chan [ 23/Jan/17 ]

Sending src/main/java/javax/servlet/ServletContext.java
Transmitting file data .done
Committing transaction...
Committed revision 64427.





[SERVLET_SPEC-144] Clarification on metadata-complete Created: 02/Oct/15  Updated: 09/Feb/17  Resolved: 02/Oct/15

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

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


 Description   

As we noticed that people seem to get confused as to the exact meaning of the xml attribute metadata-complete = "true" with regard to annotation scanning.

The intent here is not to not process all annotations, but rather to not process those annotations that are covered by the metadata of the deployment descriptors that specify metadata-complete.

While the above information is in the spec, we need to make it more explicit in the spec.



 Comments   
Comment by Shing Wai Chan [ 02/Oct/15 ]

Sending eod-pluggability.fm
Sending status.fm
Transmitting file data ..
Committed revision 113.





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

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

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

Sprint: MS 3 Sprint 1

 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

Comment by Ed Burns [ 26/Jan/17 ]

Here is a proposal that implements this.

@WebListener()
public class NewServletListener  implements ServletContextListener {

    @Override
    public void contextInitialized(ServletContextEvent sce) {

        final ServletContext servletContext = sce.getServletContext();
        final ServletRegistration.Dynamic dynamic = servletContext.addServlet("newjsp",
                ServletContext.JSP_SERVLET_CLASS_REFERENCE);
        dynamic.setJspFile("/newjsp.jsp");
        dynamic.addMapping("/newjsp");

    }

}
Comment by Ed Burns [ 26/Jan/17 ]

The use of the constant JSP_SERVLET_CLASS_REFERENCE enables the implementation to take the necessary actions to ensure this is equivalent to the implementation private JspServlet.

Comment by Shing Wai Chan [ 27/Jan/17 ]

<jsp-file> is a deployment descriptor. If the API is to set <jsp-file>, do we need to introduce the constant JSP_SERVLET_CLASS_REFERENCE?

Comment by Ed Burns [ 27/Jan/17 ]

I chose adding the constant to minimize impact on the existing API for programmatic servlet registration, which is:

@WebListener()
public class NewServletListener  implements ServletContextListener {

    @Override
    public void contextInitialized(ServletContextEvent sce) {

        final ServletContext servletContext = sce.getServletContext();
        final ServletRegistration.Dynamic dynamic = servletContext.addServlet("newjsp",
                [String, Class or Servlet]);
        dynamic.addMapping("/newjsp");

    }

}

As far as I know, and I could be wrong about this, but the existing API does require the use of one of the addServlet() variants on ServletContext. Given that assumption, neither the Class nor the Servlet variants are appropriate for a Servlet that is a JSP page. That leaves String. We have a private constant that is used internally for such things, but that is implementation specific. So, I judged the easiest and most minimal impact would be achieved by introducing a new constant whose meaning is as I've documented in the patch.

Comment by markt_asf [ 27/Jan/17 ]

I originally thought of using null. Looking at the addSevlet() Javadoc that looks legal. However, a specific constant strikes me as a better idea than giving null a special meaning.

Comment by Shing Wai Chan [ 06/Feb/17 ]

Revisions:
----------
64485

Modified Paths:
---------------
trunk/api/javaee-api/javax.servlet/src/main/java/javax/servlet/ServletContext.java

Comment by Shing Wai Chan [ 10/Feb/17 ]

add ServletContext#addJspFile()





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

Status: Resolved
Project: servlet-spec
Component/s: Filter/Servlet
Affects Version/s: None
Fix Version/s: None

Type: New Feature Priority: Major
Reporter: arjan tijms Assignee: Unassigned
Resolution: Won't Fix 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)



 Comments   
Comment by arjan tijms [ 14/Feb/17 ]

Just wondering, why was this closed?

This is still a very much needed functionality and would be greatly appreciated if it would be provided. Time and again I'm seeing code implementing this manually. In JSF it's done for Cactus, the JSR 375 Security API implements it itself, etc etc.





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

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

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

Sprint: MS 3 Sprint 2

 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.



 Comments   
Comment by Shing Wai Chan [ 08/Feb/17 ]

Here is what the spec says:

The role name “*” should never be used as an argument in calling isUserInRole. Any call to isUserInRole with “*” must return false. 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 if the user has been authenticated; that is, only when getRemoteUser and getUserPrincipal would both return a non-null value. Otherwise, the container must check the user for membership in the application role.

If "**" is used as a security role name, then it is covered by the last sentence of the spec:

Otherwise, the container must check the user for membership in the application role.

20170208-edburns: escaped * for proper rendering.

Comment by Ed Burns [ 08/Feb/17 ]

But Stuart is asking what should be the behavior when the app explicitly and declaratively does define a security-role for "**". The spec says what should be the behavior of isUserInRole() when there is no such rule, but he is saying it does not say what to do when there is such a rule. At least, that is my read of Stuart's description.

Comment by Shing Wai Chan [ 08/Feb/17 ]

From jira description above, Sturat is asking the question is for "**", not "*".
The behavior for "*" is also specified in the spec:

The role name “*” should never be used as an argument in calling isUserInRole. Any call to isUserInRole with “*” must return false.

Comment by Ed Burns [ 14/Feb/17 ]

After clarification with Shing-wai, I now agree that this issue is sufficiently handled in the existing text of the specification.





[SERVLET_SPEC-137] Allow context root Created: 20/Aug/15  Updated: 15/Sep/15  Resolved: 15/Sep/15

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

Type: Improvement Priority: Minor
Reporter: nboyce Assignee: Shing Wai Chan
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Set context root in web-inf/web.xml

Products would use the module name (for which we defined defaulting rules) as the context root unless it was overridden.



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

Would this require a change to the web_app.xsd? Reminder, those are maintained in a separate repo at <https://svn.java.net/svn/glassfish~svn/trunk/schemas>.

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

Yes, this requires a schema change.
The schemas/javaee8 directory is not there yet. We need to wait for the setup.

Comment by markt_asf [ 21/Aug/15 ]

I'm not convinced this is a good idea. Web applications should be independent of the context path at which they are deployed.

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

Per discussion in EG, we agree to add <default-context-path> element in web.xml.
Sending src/web-app_4_0.xsds
Sending src/web-common_4_0.xsds
Sending src/web-fragment_4_0.xsds
Sending test/web-app-complete.xml
Sending test/web-app-data-source.xml
Sending test/web-app-resources.xml
Sending test/web-app.xml
Sending test/web-fragment-complete.xml
Transmitting file data ........
Committed revision 64096.

Sending deployment.fm
Sending images/web-app.png
Sending servlet.book
Sending status.fm
Transmitting file data ....
Committed revision 111.





[SERVLET_SPEC-135] Adding @Deprecated for those with @deprecated in javadoc Created: 17/Aug/15  Updated: 18/Aug/15  Resolved: 18/Aug/15

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

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


 Description   

The following has @deprecated in javadoc. @Deprecated should be added in the codes.

ServletContext: #getServlet(String), #getServlets(), #getServletNames(), #log(Exception, String)

ServletRequestWrapper: #getRealPath

SingleThreadModel: class level

UnavailableException: constructors, #getServlet

HttpServletRequest: #isRequestSessionIdFromUrl()

HttpServletResponse: #encodeUrl(String), #encodeRedirectUrl(String), #setStatus(int, String)

HttpServletResponseWrapper: #encodeUrl(String), #encodeRedirectUrl(String), #setStatus(int, String)

HttpSession: #getSessionContext(), #getValue(), #getValueNames(), #putValue(), #removeValue()

HttpSessionContext: class level, #getSession(String), #getIds()

HttpUtils: class level



 Comments   
Comment by Shing Wai Chan [ 18/Aug/15 ]

Sending src/main/java/javax/servlet/ServletContext.java
Sending src/main/java/javax/servlet/ServletRequestWrapper.java
Sending src/main/java/javax/servlet/SingleThreadModel.java
Sending src/main/java/javax/servlet/UnavailableException.java
Sending src/main/java/javax/servlet/http/HttpServletRequest.java
Sending src/main/java/javax/servlet/http/HttpServletRequestWrapper.java
Sending src/main/java/javax/servlet/http/HttpServletResponse.java
Sending src/main/java/javax/servlet/http/HttpServletResponseWrapper.java
Sending src/main/java/javax/servlet/http/HttpSession.java
Sending src/main/java/javax/servlet/http/HttpSessionContext.java
Sending src/main/java/javax/servlet/http/HttpUtils.java
Transmitting file data ...........
Committed revision 64060.





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

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

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


 Description   

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

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

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

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

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

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

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

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

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



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

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

Comment by Shing Wai Chan [ 14/Aug/15 ]

Sending eod-pluggability.fm
Sending events.fm
Sending requestobject.fm
Sending responseobject.fm
Sending security.fm
Sending servlet.book
Sending servletobjects.fm
Transmitting file data .......
Committed revision 108.

Comment by Shing Wai Chan [ 05/Jan/16 ]

additional fixes

Sending requestobject.fm
Sending responseobject.fm
Transmitting file data ..
Committed revision 122.

Sending src/main/java/javax/servlet/ReadListener.java
Sending src/main/java/javax/servlet/WriteListener.java
Transmitting file data ..
Committed revision 64232.





[SERVLET_SPEC-46] "Differed" should be "deferred" in spec text on async servlet lifecycle Created: 07/Sep/12  Updated: 14/Sep/12  Resolved: 14/Sep/12

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

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


 Description   

EDR text, section 2.3.3.3 pg 11:

"Dispatching from a synchronous servlet to an asynchronous servlet would be illegal.
However the decision of throwing an IllegalStateException is differed to the
point when the application calls startAsync. This would allow a servlet to either
function as a synchronous or an asynchronous servlet."

I think "differed" should be "deferred".



 Comments   
Comment by Shing Wai Chan [ 14/Sep/12 ]

Sending servletobjects.fm
Transmitting file data .
Committed revision 43.





[SERVLET_SPEC-38] Listeners were not invoked in a random order prior to Servlet 3.0 spec Created: 01/Apr/12  Updated: 30/Jul/12  Resolved: 30/Jul/12

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

Type: Bug Priority: Minor
Reporter: Christian Ludt Assignee: Shing Wai Chan
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

Section 1.6.1 Listener ordering, a subsection of 1.6 Compatibility with Java Servlet Specification Version 2.5 states

Prior to this release of the specification, listeners were invoked in a random order. [...]

However, the Servlet Specification Version 2.5 already specified on page 78 in SRV.10.3.2 Deployment Declarations, SRV.10.3.3 Listener Registration and SRV.10.3.4 Notifications At Shutdown that the order is taken from the deployment descriptor:

SRV.10.3.2 Deployment Declarations
[...] [Listener classes] are listed by class name in the order in which they are to be invoked.

SRV.10.3.3 Listener Registration
The Web container registers the listener instances according to [...]
the order in which they appear in the deployment descriptor. During Web
application execution, listeners are invoked in the order of their registration.

SRV.10.3.4 Notifications At Shutdown
On application shutdown, listeners are notified in reverse order to their declarations
with notifications to session listeners preceeding notifications to context listeners.
Session listeners must be notified of session invalidations prior to context listeners
being notified of application shutdown.



 Comments   
Comment by Shing Wai Chan [ 30/Jul/12 ]

1. remove 1.6.1
2. Clarification in 8.2.3 (p.77) and 11.3.3

Sending eod-pluggability.fm
Sending events.fm
Sending overview.fm
Sending servletobjects.fm
Sending status.fm
Transmitting file data .....
Committed revision 39.





[SERVLET_SPEC-149] Eliminate talk of "default" context Created: 19/Nov/15  Updated: 20/Jan/17  Resolved: 20/Jan/17

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

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

Issue Links:
Duplicate
is duplicated by SERVLET_SPEC-150 Eliminate talk of "default" context Resolved

 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 Ed Burns [ 20/Jan/17 ]

Committed revision 64421.





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

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

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

Issue Links:
Duplicate
duplicates SERVLET_SPEC-149 Eliminate talk of "default" context Resolved

 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-84] Problems with links in the Servlet 3.1 Spec Created: 21/Nov/13  Updated: 23/Jan/17  Resolved: 23/Jan/17

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

Type: Bug Priority: Minor
Reporter: Arend v. Reinersdorff Assignee: Ed Burns
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Sprint: MS 2 Sprint 2

 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

Comment by Ed Burns [ 23/Jan/17 ]

Committed revision 124.





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

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

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

Sprint: MS 2 Sprint 2

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

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

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

Sprint: MS 2 Sprint 2

 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.



 Comments   
Comment by Ed Burns [ 23/Jan/17 ]

After talking with Shing-wai, I learned that we intentionally stopped including the DTDs and XSDs in the javax.servlet:javax.servlet-api JAR, because they are better maintained outside of that jar. In the case of GlassFish, they end up in the dtds and schemas directories, respectively.

Comment by paulmillar [ 24/Jan/17 ]

Hi Ed,

Thanks for the update.

Sorry, I don't follow the logic in moving the DTD and XSD from the servlet JAR file into the application/framework (i.e., GlassFish, here). The web.xml file (for example) is part of the spec., so it's a reasonable expectation that implementations may validate XML files, so will need access to the DTD. As the servlet-api jar file is maintained, any changes to the DTD/XSD should be achievable.

That aside, the bigger issue is that I couldn't find the changelog entry that documents the removal of these files.

Could you point me at the log entry that describes the file's removal?

Cheers,

Paul.

Comment by paulmillar [ 24/Jan/17 ]

Added an issue about the lack of changelog entry:

https://java.net/jira/browse/SERVLET_SPEC-168

Cheers,

Paul.

Comment by markt_asf [ 24/Jan/17 ]

For background, Tomcat provides its own implementation of the spec JARs and they contain all the necessary DTDs and XSDs required for validation.

Comment by janbartel [ 25/Jan/17 ]

Jetty too provides its own schema files, but I think it would be preferable if they were available from a jar provided by the official spec.

Comment by Ed Burns [ 25/Jan/17 ]

I agree it would be preferable, but Shing-wai and I prefer to be consistent with other Java EE specs, the majority of which do not include DTDs or Schemas in their jar artifacts. Also, please note that the production and GAV of our "official" spec jar, javax.servlet:javax.servlet-api:4.0, is not covered by the JCP spec proper, though these are covered by this page maintained by Java EE Architect Bill Shannon:

https://glassfish.java.net/wiki-archive/Maven%20Versioning%20Rules.html

Comment by paulmillar [ 26/Jan/17 ]

@janbartel you said "Jetty too provides its own schema files"

Do you mean that Jetty provides jetty-specific DTDs, or that Jetty provides the servlet DTD files?

The former I can confirm: Jetty jar files contain DTD files for validating its XML-based configuration; however, I do not see any containing the servlet DTD, nor do those servlet DTD files exist in their source-code.

That Jetty currently does not provide servlet DTD files (e.g., web-app_2_3.dtd) was the reason for opening this ticket. The result is that applications (that using Jetty framework) must include the DTD themselves. This I did (when opening this ticket) intending this to be a temporary work-around.

Naturally, I can open a support ticket against Jetty saying they should include the servlet DTD files within their distribution, as @EdBurns mentioned GlassFish currently does. It would help me in writing this ticket if the decision not to include DTD files was documented somewhere; I imagine a changelog entry would be the natural place to record such a decision (see https://java.net/jira/browse/SERVLET_SPEC-168 ).

However, I guess this ticket also describes the decision, so that could be used, too.

Cheers,

Paul.

Comment by paulmillar [ 26/Jan/17 ]

For reference, here's the ticket I opened against Jetty, requesting they include DTD files in their distribution.

https://github.com/eclipse/jetty.project/issues/1287





[SERVLET_SPEC-168] Removed DTD file not documented Created: 24/Jan/17  Updated: 26/Jan/17  Resolved: 26/Jan/17

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

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

Sprint: MS 2 Sprint 2

 Description   

In a related issue:

https://java.net/jira/browse/SERVLET_SPEC-115

I reported that DTD files are missing from the API JAR file. This issue was closed with "Works as designed".

However, I was unable to find a mention of this change (removing DTD files from the JAR file) in the changelog.

Could you point me at the log entry that describes the file's removal, or update the changelog to include this change?

Cheers,

Paul.



 Comments   
Comment by Ed Burns [ 26/Jan/17 ]

ejburns-mac:servlet-spec-1HEAD ejburns$ svn commit -m "SERVLET_SPEC-168 mention no DTD policy in changelog" status.fm
Sending status.fm
Transmitting file data .done
Committing transaction...
Committed revision 126.





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

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

Type: Task Priority: Trivial
Reporter: Ed Burns Assignee: Ed Burns
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: 0 minutes
Time Spent: 3 hours, 7 minutes
Original Estimate: Not Specified

Attachments: Text File 20161202-servlet-issue-husbandry.txt    

 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.



 Comments   
Comment by Ed Burns [ 05/Dec/16 ]

Proposed JIRA Components, by decreasing order of issues in each component

COMP: Configuration (17)
COMP: Container (15)
COMP: HTTP (15)
COMP: Paths/Mappings (14)
COMP: Security (13)
COMP: I/O (10)
COMP: API (8)
COMP: Filter/Servlet (6)
COMP: Listeners (4)
COMP: Sessions (2)
COMP: Project Management (1)
COMP: Deployment (0)

Comment by Ed Burns [ 06/Dec/16 ]

SW> I am not sure about the Paths/Mappings.

EB> I'll drop that one. My intent was to be for issues that have to do with
EB> the mapping of servlets and filters and anything to do with what appears
EB> in the first line of the HTTP request. Do you have another suggestion
EB> for the ones I have in that component? Let me know and I'll add it.

SW> Should we have a Other or Misc?

EB> Yes, good idea. I'll add that as well. I'll put the Paths/Mappings ones
EB> in there until I hear from you with another suggestion.





[SERVLET_SPEC-76] Javadoc coding error in javax.servlet.http.HttpSession interface Created: 29/Jul/13  Updated: 30/Jul/13  Resolved: 30/Jul/13

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

Type: Bug Priority: Trivial
Reporter: Kim Haase Assignee: Shing Wai Chan
Resolution: Fixed Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified


 Description   

If you look at the page source for http://docs.oracle.com/javaee/7/api/javax/servlet/http/HttpSession.html you will see that the documentation for the setAttribute method contains "<code>" instead of "</code>" after the "()" at the end of this sentence:

If the value passed in is null, this has the same effect as calling removeAttribute().

This causes all the rest of the documentation for this interface to be in code font.

I can make the fix in the HTML output on the web site, but it should be fixed in source so that the erroneous code is not generated in the future. (The problem has actually been there since J2EE 1.3.1 – it was just recently called to my attention.)

This should be an easy fix.



 Comments   
Comment by Shing Wai Chan [ 30/Jul/13 ]

Sending HttpSession.java
Transmitting file data .
Committed revision 62430.





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

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

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


 Description   

Missing @since 4.0



 Comments   
Comment by Ed Burns [ 20/Jan/17 ]

Committed revision 64420.





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

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

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

Attachments: Text File 20170207-2128Z-SERVLET_SPEC-88.patch    
Sprint: MS 3 Sprint 1

 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?



 Comments   
Comment by Ed Burns [ 09/Feb/17 ]

bash-4.1$ svn commit -F changebundle.txt src/main/java/javax/servlet/http/HttpServletResponse.java
Sending src/main/java/javax/servlet/http/HttpServletResponse.java
Transmitting file data .
Committed revision 64527.





[SERVLET_SPEC-170] Update LICENSE.txt for compliance Created: 13/Feb/17  Updated: 13/Feb/17  Resolved: 13/Feb/17

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

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

Sprint: MS 3 Sprint 2

 Description   

See Ed Bratt email.



 Comments   
Comment by Ed Burns [ 13/Feb/17 ]

Turns out this already appears to come for free via maven grabbing the license from the master copy.





Generated at Mon Feb 20 09:01:58 UTC 2017 using JIRA 6.2.3#6260-sha1:63ef1d6dac3f4f4d7db4c1effd405ba38ccdc558.