>>>>> On Thu, 27 Apr 2017 15:07:26 +0100, Mark Thomas <markt_at_apache.org> said:
MT> Please find below the results of my review of the spec document. I still
MT> need to look through the Javadoc. I'll send another mail if I find
MT> anything there.
Thank you very much for this thorough review.
MT> Finally, there look to be a handful of currently open issues asking for
MT> clarification or minor additions that we could address in time for the
MT> final version.
I hope they can be addressed also.
MT> Preface references RFC 2965
MT> The vast majority of user agents never implemented this spec.
MT> Historically, the Servlet API is based on RFC 2109. We should be
MT> referencing RFC 6265. RFC 6265 is more restrictive than RFC 2109 in a
MT> number of areas. We need to update the API to define behaviour if a
MT> value that does not comply with RFC 6265 is passed. My initial thoughts
MT> are throw an IllegalArgumentException. See SERVLET_SPEC-37.
Can you please provide a little more context? I looked at issues/37.
First, I didn't see any reference in the spec pdf or javadoc to 2019.
Second, throw an IEA from where? In any case, I replaced 2965 with 6265
in the preface.
MT> Section 2.3.3.3 Page 2-16
MT> s/complete/dispatch/ in the first sentence of the modified text.
FIXED.
MT> Section 2.3.3.3 Page 2-17
MT> complete isn't formatted as code in the first sentence of the
MT> modified text.
FIXED.
MT> Section 3.12 Page 3-31
MT> See discussion on list for updated text.
Yes, for issues/173.
MT> Section 5.6 Page 5-50
MT> Possible clarification in the inserted text:
MT> "... explicitly set the default encoding ..."
Sure. FIXED.
MT> Section 6.2.4 Page 6-58
MT> s/Multipe/Multiple/g
FIXED.
MT> Section 7.5 Page 7-66
MT> s/seesion/session/
FIXED
MT> Section 9.3.1 Page 9-101
MT> I thought we agreed to name the new attribute
MT> javax.servlet.include.servlet_mapping
MT> to align with the associated methods and to avoid possible future conflicts
MT> Also for forward and async attributes
I'm open to being corrected on this, but my mail archive searching
supports the current names for these now things:
>>>>> On Thu, 16 Feb 2017 14:41:00 -0800, Edward Burns <edward.burns_at_oracle.com> said:
EB> Thanks for your patience on this. This reply is culled from
EB> reviewing the discussion on users_at_servlet-spec as well as on this
EB> list. Comments inline.
>>>>> On Fri, 10 Feb 2017 09:11:43 +0000, Mark Thomas <markt_at_apache.org> said:
MT> Yes. Specifically this part of the thread:
MT>
https://java.net/projects/servlet-spec/lists/users/archive/2016-04/message/7
EB> Right, that's important:
MT> I think we need to follow the same rules as for the path of the
MT> original request. That means we'll need some new request
MT> attributes. Something like:
MT> javax.servlet.forward.mapping
MT> javax.servlet.include.mapping
MT> If folks think this is sensible, I can add implementing this to my
MT> TODO list for the next Tomcat milestone so folks can try it out.
Paul Penedict wrote:
PB> Question on the mapping. If a request comes into a servlet and the
PB> servlet includes/forwards to a JSP, what does the JSP see? I presume
PB> it will be the Mapping of the implicit *.jsp servlet, correct? Will
PB> there be any special request attributes to expose the servlet's --
PB> something to the effect like the javax.servlet.include/forward
PB> attributes?
MT> Returns the original mapping. The mapping for the include is available via
MT> RequestDispatcher.INCLUDE_MAPPING / javax.servlet.include.mapping
MT> Section 10.7.1 Page 10-11
MT> Since Servlet 4 has a minimum of Java 8, this should probably link to
MT> the Java 8 version of these docs rather than the Java 7 version.
MT> Section 14.5.x
MT> The examples should reference Servlet 4.0 XSD
These were helpfully pointed out by users member Arend Reinersdorf and
I fixed them.
Ed
--
| edward.burns_at_oracle.com | office: +1 407 458 0017