HTTP headers and end of response, reposted for better reading
Hi all,
(repost for better reading)
I am working at an inplementation of RFC2671 Digest Authentication.
I want to do the authentication in my servlet application because I need
additional data with
the userid and password. For reasons of session management and security I
should be able
to send an Authentication-Info header in my response.
This is the commonly accepted implementation scheme: If the login fails a 401
is sent thus:
new login, when the login is ok an Authentication-Info header is send together
with the normal
200 OK response.
So what, "You can set headers in the HttpServletResponse" would one say, but
here's a problem:
RFC2617 literally states: "The Authentication-Info" header is allowed in the
trailer of an HTTP
message transferred via chunked transfer encoding".
Some browsers (MSIE and Mozilla) have taken this as: '... is ONLY allowed ...'.
I had a discussion with Paul Leach from Microsoft, one of the co-authors of
RFC2617, and he
pointed out that the reason for it was that with a given quality of protection
("auth-int") the content
of the message is part of the calculation to check wether the
Authentication-Info header is valid
and "for that reason" (huh?) the Authentication-Info header has to follow the
message content
block (funny enough MSIE and Mozilla do not support this option, only Opera
does).
However, the placement of HTTP headers at the end of a response is currently
not supported in
Tomcat.
This all brings me in a stalemate position: IE and Mozilla are the most widely
used browsers by
far but will only accept the Authentication-Info header at the end but Tomcat
does not support this.
This leaves only the "standard" options for digest athentication: a fairly
simple check against
userid:password pairs, which is not acceptable for me ( no user categories,
only atomic userid's,
database replications needed, no addtional data allowed when checking login,
less detection of
tampering, no password change polices, no "invisible" digest changes, session
management by
cookies, etc).
I realize that the implementation of "trailing headers" means implications for
the Servlet API,
something like: HttpServletResponse.setHeader(String name, String value,
boolean atEnd).
So I had the idea to prefix the header name with a + sign to indicate that the
header should follow
the content and that chunked encoding should be in place. I had a look at the
Response source
code, but until now it was not very clear to me how to implement the trick.
To conclude, of course my preferred suggestion would be: append a boolean
argument to the
setHeader methods of the HttpServletResponse interface, not to the addHeader of
course and
add a method: isHeaderAtEnd (String name) to detect wether the header is before
or after the
content. This suggestions should be followed by all servlet engine implementors.
The + sign prepending "trick" would not have implications for the Servlet API.
When looking at
the Tomcat source I cannot oversee what sources would be affected, especially
those involved
in connectors.
Now that was a long story, who can help me ?
KR, Hans
HTTP headers and end of response
Hi all,
I am working at an inplementation of RFC2671 Digest Authentication. I want to
do the authentication in my servlet application because I need additional data
with the userid and password. For reasons of session management and security I
should be able to send an Authentication-Info header in my response. This is
the commonly accepted implementation: If the login fails a 401 is sent thus:
new login, when the login is ok an Authentication-Info header is send together
with the normal 200 OK response.
So what, "You can set headers in the HttpServletResponse" would one say, but
here's a problem: RFC2617 literally states: "The Authentication-Info" header is
allowed in the trailer of an HTTP message transferred via chunked transfer
encoding".
Some browsers (MSIE and Mozilla) have taken this as: '... is ONLY allowed ...'.
I had a discussion with Paul Leach from Microsoft, one of the co-authors of
RFC2617, and he pointed out that the reason for it was that with a given
quality of protection ("auth-int") the content of the message is part of the
calculation to check wether the Authentication-Info header is valid and "for
that reason" (huh?) the Authentication-Info header has to follow the message
content block (funny enough MSIE and Mozilla do not support this option, only
Opera does).
However, the placement of HTTP headers at the end of a response is currently
not supported in Tomcat.
This all brings me in a stalemate position: IE and Mozilla are the most used
browsers by far but will only accept the Authentication-Info header at the end
but Tomcat does not support this. This leaves only the "standard" options for
digest athentication: a fairly simple check against userid:password pairs,
which is not acceptable for me ( no user categories, only atomic userid's,
database replications needed, no addtional data allowed when checking login,
less detection of tampering, no password change polices, no "invisible" digest
changes, session management by cookies, etc).
I realize that the implementation of "trailing headers" means implications for
the Servlet API, something like: HttpServletResponse.setHeader(String name,
String value, boolean atEnd). So I had the idea to prefix the header name with
a + sign to indicate that the header should follow the content and that chunked
encoding should be in place. I had a look at the Response source code, but
until now it was not very clear to me how to implement the trick.
To conclude, of course my preferred suggestion would be: append a boolean
argument to the setHeader methods of the HttpServletResponse interface, not to
the addHeader of course and add a method: isHeaderAtEnd (String name) to detect
wether the header is before or after the content. This suggestions should be
followed by all servlet engine implementors.
The + sign prepending "trick" would not have implications for the Servlet API.
When looking at the Tomcat source I cannot oversee what sources would be
affected, especially those involved in connectors.
Now that was a long story, who can help me ?
KR, Hans
