2015-09-13 14:55 GMT+03:00  <ma...@apache.org>:
> Author: markt
> Date: Sun Sep 13 11:55:39 2015
> New Revision: 1702765
>
> URL: http://svn.apache.org/r1702765
> Log:
> RFC 7230 states that clients should ignore reason phrases in HTTP/1.1 
> response messages. Since the reason phrase is optional, Tomcat no longer 
> sends it.
> As a result the system property 
> <code>org.apache.coyote.USE_CUSTOM_STATUS_MSG_IN_HEADER</code> is no longer 
> used and has been removed.
>

1. I verified that it is optional in legacy HTTP/1.0 specification as
well (RFC 1945)

       Status-Line = HTTP-Version SP Status-Code SP Reason-Phrase CRLF

       Reason-Phrase  = *<TEXT, excluding CR, LF>


2. I suspect that there might be non-browser clients, that may use
reason phrase. There may be some specific-use (targeted) clients, that
may break.

Personally I would prefer that this feature were optional.

An example: XMLHttpRequest object has statusText  property. If someone
uses it to display an error message, showing "404 Not Found" is better
than just "404". The reason phrase is useless, but it provides context
that helps a human user to interpret "404" as HTTP status code and not
some random numeric.
https://developer.mozilla.org/ru/docs/Web/API/XMLHttpRequest

3. Reviewing Servlet API,
 (HttpServletResponse#sendError(int,String), #setStatus(int, String)).

The sendError() does not mention that the string is a reason phrase,
but says that it will be used in text of a HTML error page. So we are
OK here.

The 2-arguments setStatus() method is deprecated. From javadoc one may
think that "the status message" argument here is the reason phrase.
If anybody relies on this behaviour, it is now broken.  Maybe clarify
the javadoc.

We are OK to change a depreated method, as it is bad to rely on
deprecated methods. But the reason for deprecation says that the
method is ambiguous, not that it is broken.


Best regards,
Konstantin Kolinko

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Reply via email to