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.
Sincerely,
M. Nawazish. Khan
On Fri, May 23, 2014 at 7:00 PM, <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>
> 2. [servlet-spec users] [jsr340-experts] Re: Server-Sent Events in Java EE
> 8 - Wenbo Zhu <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>
>
>
>
> ---------- Forwarded message ----------
> From: Shing Wai Chan <shing.wai.chan_at_oracle.com>
> To: "jsr340-experts_at_servlet-spec.java.net" <
> 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
>
> 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>
> To: shing.wai.chan_at_oracle.com
> Cc: "jsr340-experts_at_servlet-spec.java.net" <
> 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
> > 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
>>
>> 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>
> To: 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 - Sat, 24 May 2014
>
>