On Thu, Feb 9, 2017 at 11:13 AM, Mark Thomas <markt_at_apache.org> wrote:
> On 08/02/17 23:42, Greg Wilkins wrote:
>>
>> Ed,
>>
>> I'm not really happy with giving an undertaking to include messages
>> without any escaping or re-encoding. If an attack vector is discovered
>> that relies on injecting text into an error message, then I think
>> containers will naturally react by escaping and/or encoding. I don't
>> think the spec should ban a prime defence mechanism.
>>
>> More over, the generation of an error page may be beyond the knowledge
>> of the calling application. HTML is only the default and some servers
>> may be configured to send XML or JSON encoded error pages. A calling
>> application cannot know what encoding will result.
>>
>> The message is passed as a unicode string, so it should be up to the
>> container how that is encoded, or even if it is encoded. I certainly
>> have seen configurations where such error messages are not sent to the
>> client.
>>
>>
>> If the calling application wishes to control the content of the error
>> page, they are free to call setStatus, setContentType, etc and generate
>> the page themselves. If they wish to delegate generation of the error
>> page to the container, then they pass minimal information and how or
>> even if that is encoded is beyond their control.
>
>
> Somewhere between me opening SERVLET_SPEC-88 and Ed asking for feedback
> yesterday I misremembered my original thinking on this issue. Sorry.
>
> My original position was aligned with Greg's. The component generating the
> error page should take care of any necessary escaping / encoding since it
> knows what format is being used whereas the caller of sendError probably
> does not.
>
> Taking Ed's improved text and adapting it gives:
>
> * The caller is not responsible for escaping or re-encoding the
> * message to ensure it is safe with respect to the current
> * response encoding and content type. That is the responsibility
> * of the component generating the error page.
>
>
> Possibly re-word that last bit as "of the container as the generator of the
> error page."
+1
If the application wants complete control it should generate the error
page itself, otherwise it has to be up to the container to make sure
the generated content is safe.
Stuart
>
> Mark
>
>
>>
>>
>> regards
>>
>>
>>
>> On 9 February 2017 at 09:58, Edward Burns <edward.burns_at_oracle.com
>> <mailto:edward.burns_at_oracle.com>> wrote:
>>
>>
>> On 07/02/17 22:34, Edward Burns wrote:
>>
>> EB> I propose we resolve this by adding this statement to the text of
>> EB> HttpServletResponse.sendError(), after "text/html":
>>
>> EB> The message is assumed to be in the character
>> EB> encoding of the current response.
>>
>> >>>>> On Tue, 7 Feb 2017 23:37:40 +0000, Mark Thomas
>> <markt_at_apache.org <mailto:markt_at_apache.org>> said:
>>
>> MT> That text does not address the primary concern of addressing who
>> is
>> MT> responsible for ensuring that the message is safe to use as is.
>>
>> MT> I'd suggest the following alternative text:
>>
>> MT> The caller is responsible for ensuring that the provided message
>> is safe
>> MT> (e.g. user provided data is appropriately escaped) to be included
>> MT> 'as-is' in the error response.
>>
>> I hope you don't mind if I reword your text as
>>
>> * The argument message will be included in the
>> * response without any escaping or re-encoding. The caller is
>> * responsible for ensuring this is safe with respect to the
>> current
>> * response encoding.
>>
>> Is that ok?
>>
>> Thanks,
>>
>> Ed
>>
>> --
>> | edward.burns_at_oracle.com <mailto:edward.burns_at_oracle.com> | office:
>> +1 407 458 0017 <tel:%2B1%20407%20458%200017>
>> | 19 business days until planned start of JSF 2.3 Final Approval
>> Ballot
>> | 9 business days until DevNexus 2017
>> | 34 business days until JavaLand 2017
>>
>>
>>
>>
>> --
>> Greg Wilkins <gregw_at_webtide.com <mailto:gregw_at_webtide.com>> CTO
>> http://webtide.com
>
>