On 26/05/2014 10:31, Mohammad Nawazish Khan wrote:
> Hi,
>
> As the component (generating error message) already has access to the
> ACCEPT Header of the client, it would be more safer that the error
> messages could be send in the same format for rendering with client as
> its ACCEPT Header, rather than the more generic "text/html" error responses.
Determining the format to be used for an error message response is a
different topic. If you want to propose something for that, please do so
in a separate thread.
Mark
>
> Sincerely,
> M. Nawazish. Khan
>
>
> On Mon, May 26, 2014 at 7:30 AM, <users-request_at_servlet-spec.java.net
> <mailto:users-request_at_servlet-spec.java.net>> wrote:
>
> Table of contents:
>
> 1. [servlet-spec users] Re: Digest for list
> users_at_servlet-spec.java.net <mailto:users_at_servlet-spec.java.net> -
> Mark Thomas <markt_at_apache.org <mailto:markt_at_apache.org>>
>
>
>
> ---------- Forwarded message ----------
> From: Mark Thomas <markt_at_apache.org <mailto:markt_at_apache.org>>
> To: users_at_servlet-spec.java.net <mailto:users_at_servlet-spec.java.net>
> Cc:
> Date: Sun, 25 May 2014 09:07:18 +0100
> Subject: [servlet-spec users] Re: Digest for list
> users_at_servlet-spec.java.net <mailto:users_at_servlet-spec.java.net>
> On 24/05/2014 13:56, Mohammad Nawazish Khan wrote:
> > Hi,
> >
> > As is generally the case, a client would like to have error
> messages in
> > the same format as it would like to have all positive responses
> from the
> > server. With this premise, in my humble opinion, while calling
> > HttpServletResponse.sendError (int, String), the caller could further
> > intimate the underlying (Servlet) Container with the "ACCEPT" header
> > encapsulated within HttpServletRequest. So that when Container
> generates
> > the error message, it would generate it in the format (ACCEPT Header)
> > the client requires it.
> >
> > We may have the sendError () signature updated as: sendError (int,
> > String, String); where the third String type parameter corresponds to
> > the ACCEPT Header of the request.
> >
> > I would wait to hear what the Expert Group think about it.
>
> -1. The component generating the response already has access to the
> accept header. There is no need to pass it in on the sendError() call.
>
> Mark
>
>
> >
> > Sincerely,
> > M. Nawazish. Khan
> >
> >
> >
> >
> > On Fri, May 23, 2014 at 7:00 PM,
> <users-request_at_servlet-spec.java.net
> <mailto:users-request_at_servlet-spec.java.net>
> > <mailto:users-request_at_servlet-spec.java.net
> <mailto:users-request_at_servlet-spec.java.net>>> wrote:
> >
> > Table of contents:
> >
> > 1. [servlet-spec users] [jsr340-experts] Server-Sent Events in
> Java
> > EE 8 - Shing Wai Chan <shing.wai.chan_at_oracle.com
> <mailto:shing.wai.chan_at_oracle.com>
> > <mailto:shing.wai.chan_at_oracle.com
> <mailto:shing.wai.chan_at_oracle.com>>>
> > 2. [servlet-spec users] [jsr340-experts] Re: Server-Sent Events in
> > Java EE 8 - Wenbo Zhu <wenbozhu_at_gmail.com
> <mailto:wenbozhu_at_gmail.com> <mailto:wenbozhu_at_gmail.com
> <mailto:wenbozhu_at_gmail.com>>>
> > 3. [servlet-spec users] [jsr340-experts] Re: Responsibility
> for safe
> > use of message in HttpServletResponse.sendError(int, String) -
> Shing
> > Wai Chan <shing.wai.chan_at_oracle.com
> <mailto:shing.wai.chan_at_oracle.com> <mailto:shing.wai.chan_at_oracle.com
> <mailto:shing.wai.chan_at_oracle.com>>>
> >
> >
> >
> > ---------- Forwarded message ----------
> > From: Shing Wai Chan <shing.wai.chan_at_oracle.com
> <mailto:shing.wai.chan_at_oracle.com>
> > <mailto:shing.wai.chan_at_oracle.com
> <mailto:shing.wai.chan_at_oracle.com>>>
> > To: "jsr340-experts_at_servlet-spec.java.net
> <mailto:jsr340-experts_at_servlet-spec.java.net>
> > <mailto:jsr340-experts_at_servlet-spec.java.net
> <mailto:jsr340-experts_at_servlet-spec.java.net>>"
> > <jsr340-experts_at_servlet-spec.java.net
> <mailto:jsr340-experts_at_servlet-spec.java.net>
> > <mailto:jsr340-experts_at_servlet-spec.java.net
> <mailto:jsr340-experts_at_servlet-spec.java.net>>>
> > Cc:
> > Date: Fri, 23 May 2014 09:44:39 -0700
> > Subject: [servlet-spec users] [jsr340-experts] Server-Sent
> Events in
> > Java EE 8
> > We plan to have Server-Sent Events in Java EE 8.
> > There are several options discussed in Java EE alias:
> >
> >
> https://java.net/projects/__javaee-spec/lists/jsr342-__experts/archive/2014-05/__message/10
> >
> <https://java.net/projects/javaee-spec/lists/jsr342-experts/archive/2014-05/message/10>
> >
> >
> > The current plan of record is to provide "no" API for SSE in
> Servlet.
> > I am leaving the door open, however. Some conditions must be met:
> > * There is a compelling use case
> > * It can be done cleanly
> > * It adds value
> > * The Servlet EG wants it
> > * It is complementary to the corresponding API in JAX-RS 2.0.
> > (Note there are other areas of overlap between JAX-RS and
> Servlet and
> > no-one seems to mind:
> > Servlet JAX-RS
> >
> > AsyncContext AsyncResponse
> >
> > Non-Blocking IO TBD in JAX-RS 2.1
> > ReadListener
> > WriteListener
> > )
> >
> > The current plan of record does call for standardizing HTTP
> 2.0 server
> > push in Servlet 4.0. That work may reveal more facts to sway the
> > decision.
> >
> > We would like to listen to opinions of Servlet EG.
> >
> > Shing Wai Chan
> >
> >
> >
> >
> >
> > ---------- Forwarded message ----------
> > From: Wenbo Zhu <wenbozhu_at_gmail.com
> <mailto:wenbozhu_at_gmail.com> <mailto:wenbozhu_at_gmail.com
> <mailto:wenbozhu_at_gmail.com>>>
> > To: shing.wai.chan_at_oracle.com
> <mailto:shing.wai.chan_at_oracle.com> <mailto:shing.wai.chan_at_oracle.com
> <mailto:shing.wai.chan_at_oracle.com>>
> > Cc: "jsr340-experts_at_servlet-spec.java.net
> <mailto:jsr340-experts_at_servlet-spec.java.net>
> > <mailto:jsr340-experts_at_servlet-spec.java.net
> <mailto:jsr340-experts_at_servlet-spec.java.net>>"
> > <jsr340-experts_at_servlet-spec.java.net
> <mailto:jsr340-experts_at_servlet-spec.java.net>
> > <mailto:jsr340-experts_at_servlet-spec.java.net
> <mailto:jsr340-experts_at_servlet-spec.java.net>>>
> > Date: Fri, 23 May 2014 14:16:34 -0700
> > Subject: [servlet-spec users] [jsr340-experts] Re: Server-Sent
> > Events in Java EE 8
> >
> >
> >
> > On Fri, May 23, 2014 at 9:44 AM, Shing Wai Chan
> > <shing.wai.chan_at_oracle.com <mailto:shing.wai.chan_at_oracle.com>
> <mailto:shing.wai.chan_at_oracle.com
> <mailto:shing.wai.chan_at_oracle.com>>> wrote:
> >
> > We plan to have Server-Sent Events in Java EE 8.
> > There are several options discussed in Java EE alias:
> >
> >
> https://java.net/projects/__javaee-spec/lists/jsr342-__experts/archive/2014-05/__message/10
> >
> <https://java.net/projects/javaee-spec/lists/jsr342-experts/archive/2014-05/message/10>
> >
> >
> > The current plan of record is to provide "no" API for SSE in
> > Servlet.
> >
> > +1
> >
> > It's not clear that this is a widely adopted API. For serious
> > notification support, the proposed protocol support is
> insufficient
> > either.
> >
> >
> >
> > I am leaving the door open, however. Some conditions must
> be met:
> > * There is a compelling use case
> > * It can be done cleanly
> > * It adds value
> > * The Servlet EG wants it
> > * It is complementary to the corresponding API in JAX-RS 2.0.
> > (Note there are other areas of overlap between JAX-RS and
> > Servlet and
> > no-one seems to mind:
> > Servlet JAX-RS
> >
> > AsyncContext AsyncResponse
> >
> > Non-Blocking IO TBD in JAX-RS 2.1
> > ReadListener
> > WriteListener
> > )
> >
> > The current plan of record does call for standardizing
> HTTP 2.0
> > server
> > push in Servlet 4.0.
> >
> > This is fine, but please note that server-push (SPDY or
> HTTP/2) has
> > little to do with server-initiated notification support.
> >
> > - Wenbo
> >
> >
> >
> > That work may reveal more facts to sway the
> > decision.
> >
> > We would like to listen to opinions of Servlet EG.
> >
> > Shing Wai Chan
> >
> >
> >
> >
> >
> >
> > ---------- Forwarded message ----------
> > From: Shing Wai Chan <shing.wai.chan_at_oracle.com
> <mailto:shing.wai.chan_at_oracle.com>
> > <mailto:shing.wai.chan_at_oracle.com
> <mailto:shing.wai.chan_at_oracle.com>>>
> > To: jsr340-experts_at_servlet-spec.java.net
> <mailto:jsr340-experts_at_servlet-spec.java.net>
> > <mailto:jsr340-experts_at_servlet-spec.java.net
> <mailto:jsr340-experts_at_servlet-spec.java.net>>
> > Cc:
> > Date: Fri, 23 May 2014 16:27:45 -0700
> > Subject: [servlet-spec users] [jsr340-experts] Re: Responsibility
> > for safe use of message in HttpServletResponse.sendError(int,
> String)
> > On 5/22/14, 2:50 PM, Mark Thomas wrote:
> >
> > All,
> >
> > When an application calls HttpServletResponse.sendError(__int,
> > String) the
> > Javadoc states that:
> >
> > <quote>
> > 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".
> > </quote>
> >
> > 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?
> >
> > +1
> >
> > Shing Wai Chan
> >
> >
> > Cheers,
> >
> > Mark
> >
> >
> >
> > End of digest for list users_at_servlet-spec.java.net
> <mailto:users_at_servlet-spec.java.net>
> > <mailto:users_at_servlet-spec.java.net
> <mailto:users_at_servlet-spec.java.net>> - Sat, 24 May 2014
> >
> >
>
>
> End of digest for list users_at_servlet-spec.java.net
> <mailto:users_at_servlet-spec.java.net> - Mon, 26 May 2014
>
>