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.
Sincerely,
M. Nawazish. Khan
On Mon, May 26, 2014 at 7:30 AM, <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 -
> Mark Thomas <markt_at_apache.org>
>
>
>
> ---------- Forwarded message ----------
> From: Mark Thomas <markt_at_apache.org>
> To: 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
> 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>> 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>>
> > 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
> >>
> > 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>>
> >
> >
> >
> > ---------- Forwarded message ----------
> > From: Shing Wai Chan <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>"
> > <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>>
> > To: 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>"
> > <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>>
> 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>>
> > To: 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> - Sat, 24 May 2014
> >
> >
>
>
> End of digest for list users_at_servlet-spec.java.net - Mon, 26 May 2014
>
>