Hi Bernd,
A fair question. The Throwable.printStackTrace() call goes to the standard
error stream, which is *usually* not mixed with the HTTP response collected
from stdout and thus shouldn't spoil the protocol. But this really depends on
how it's invoked. My assumption is that stderr is usually connected to
somewhere suitable like an error log file, but this isn't always the case.
Unfortunately the handler methods don't have any better place to send error
output. Reformatting it into a valid HTTP error response and sending it back to
the client is bad form. One could open a log file and send it there, I suppose,
but this seems worse than just relying on the calling web server to have
redirected stderr somewhere reasonable.
The CGI wrappers for this class (src/windows/bin/java-rmi.c and
src/solaris/bin/java-rmi.cgi.sh) inherit stderr from their invoker.
As for whether anybody uses this ... well, if you hear of anybody, please let
me know. We do have a test for it -- closed source, unfortunately -- which has
started failing, which is the main impetus for this change. (We suspect a
configuration issue in our test environment.)
Thanks for looking.
s'marks
On 6/27/13 2:11 PM, Bernd Eckenfels wrote:
Hello,
(sorry for answering to security-dev, I am not subscribed to the others)
the printStackTrace() seems wrong. This will ruin the HTTP Headers produced by
returnXXXError() (if it is not too late at that point anyway as the execute()
might also write data before).
I also think that if you want to output the stack trace, it should be done
inside those two handlers.
BTW: Is somebody really using this?
Greetings
Bernd
Am 27.06.2013, 22:33 Uhr, schrieb <stuart.ma...@oracle.com>:
Changeset: 6729f7ef94cd
Author: smarks
Date: 2013-06-27 13:35 -0700
URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6729f7ef94cd
8019224: add exception chaining to RMI CGIHandler
Reviewed-by: darcy
! src/share/classes/sun/rmi/transport/proxy/CGIHandler.java
