jsr369-experts@servlet-spec.java.net

[jsr369-experts] Re: SERVLET_SPEC-88-ResponseSendErrorEncoding

From: Edward Burns <edward.burns_at_oracle.com>
Date: Thu, 9 Feb 2017 11:49:20 -0800

On 07/02/17 22:34, Edward Burns wrote:

EB> I hope you don't mind if I reword your text as
EB>
EB> * The argument message will be included in the
EB> * response without any escaping or re-encoding. The caller is
EB> * responsible for ensuring this is safe with respect to the current
EB> * response encoding.

>>>>> On Wed, 8 Feb 2017 23:36:58 +0000, Mark Thomas <markt_at_apache.org> said:

MT> Clearer than mine. Thanks. I think it needs " and content type" inserted
MT> at the end.

>>>>> On Thu, 9 Feb 2017 10:42:23 +1100, Greg Wilkins <gregw_at_webtide.com> said:

GW> I'm not really happy with giving an undertaking to include messages without
GW> any escaping or re-encoding. If an attack vector is discovered that relies
GW> on injecting text into an error message, then I think containers will
GW> naturally react by escaping and/or encoding. I don't think the spec
GW> should ban a prime defence mechanism.

>>>>> On Thu, 9 Feb 2017 00:13:28 +0000, Mark Thomas <markt_at_apache.org> said:

MT> Somewhere between me opening SERVLET_SPEC-88 and Ed asking for feedback
MT> yesterday I misremembered my original thinking on this issue. Sorry.

That did throw me for a loop, but then again, #spicerfacts. Thanks for
your prompt engagement.

MT> My original position was aligned with Greg's. The component generating
MT> the error page should take care of any necessary escaping / encoding
MT> since it knows what format is being used whereas the caller of sendError
MT> probably does not.

MT> Taking Ed's improved text and adapting it gives:

MT> * The caller is not responsible for escaping or re-encoding the
MT> * message to ensure it is safe with respect to the current
MT> * response encoding and content type. That is the responsibility
MT> * of the component generating the error page.

MT> Possibly re-word that last bit as "of the container as the generator of
MT> the error page."

>>>>> On Thu, 9 Feb 2017 11:23:31 +1100, Stuart Douglas <sdouglas_at_redhat.com> said:

SD> +1

SD> If the application wants complete control it should generate the error
SD> page itself, otherwise it has to be up to the container to make sure
SD> the generated content is safe.

I will go with:

   * The caller is <strong>not</strong> responsible for escaping or
   * re-encoding the message to ensure it is safe with respect to the
   * current response encoding and content type. This aspect of safety
   * is the responsibility of the container, as it is generating the
   * error page containing the message.

Ed

-- 
| edward.burns_at_oracle.com | office: +1 407 458 0017
| 18 business days until planned start of JSF 2.3 Final Approval Ballot
|  8 business days until DevNexus 2017
| 33 business days until JavaLand 2017