On Mon, 2002-10-21 at 11:57, Nikola Milutinovic wrote:
Filip Sergeys tc wrote:
> Hi,
>
> Maybe somebody in the near or distant future will hit the same problem.
> I hope this can help you avoiding it.
>
> Error "HTTP spoken on HTTPS port" using apache 1.3.26 with mod_ssl,
> mod_jk1.2 and tomcat 4.1.12.
If I understand correctly, a client has connected to the HTTPS port and insted
of initializing a SSL handshake, started talking HTTP.
The client has connect to https port, and handshake was succesfull. The
GET request from the client was received by apache and send to tomcat.
Up to here, the communication is correct.
> Error Description:
> Requesting certain jsp pages via https gave us an error page back saying
> we are trying to talk plain HTTP to a HTTPS server, while other pages
> where served perfectly.
> After long searching throug the access_logs and ssl_engine_logs we
> found that this caused the error: "sendRedirect"
> Those pages that gave the error use "sendRedirect" in their code (we use
> it to let one jsp page take the request and let another jsp page do the
> respons).
Strange, but I guess you have determined that to be the cause. Or that cousing
something else that leads to the error.
> What does sendRedirect do?
> sendRedirect launches a new HTTP request, and this request goes via
> apache again(you can see it in the apache access_log). However this
> request is in plain HTTP while the apache server is expecting HTTPS
> request(see details below). This is, I presume, causing the error. If
> somebody know the gory detail to this... I'm interested
Well, "sendRedirect" actaully doesn't launch another HTTP request - it is a job
for the client to do so if it wishes. "sendRedirect" will send a HTTP response
to the client of the form:
Status: 304 Redirect
Location: <location given in "sendRedirect">
The server then closes the request (HTTP/1.1 might leave the connection open,
but the request is finished). The client may report on this or take further
action in changing it's location to the one given in response. *The client will
the initialte a new HTTP request* with the new location as URI.
Ah, I didn't know that. So the redirect is done via the client.
OK what does this mean? The client does a new request(previous one was
closed, right?), apparently on port 443 again (how come?), but the
request is not encrypted. Causing an error on the apache side (handshake
fails because request in plain HTTP). Is this a browser error then. I
happens both in NS/Mozilla and IE.
> (see access_log and ssl_engine_log)
> Browser requests secure connection, handshake is successfull
> Browser sends GET request to apache server for pageX.jsp over HTTPS
> Apache decrypts and forwards request to tomcat using mod_jk
> Tomcat processes page and does sendRedirect.
> New HTTP request is send to apache (while apache is still in HTTPS
> session)
> Try to do handshake again, fails. HTTP spoken on HTTPS port.
> Error page is send back to browser.
This sounds like a browser error. BTW, I'm not up to speed with HTPPS, I thought
it was just a plain HTTP over SSL connection. Is there some "session" element to
it? Can you route two requests over HTTPS connection? Is HTTPS as a protocol
different from HTTP?
HTTPS is indeed HTTP over SSL. SSL session is for caching information so
that on consequent requests the whole handshaking stuff is not to be
redone again.
I got this from the mod_ssl manual:
--start quote--
Session Establishment
The SSL session is established by following a handshake sequence between
client and server, as shown in Figure 1. This sequence may vary,
depending on whether the server is configured to provide a server
certificate or request a client certificate. Though cases exist where
additional handshake steps are required for management of cipher
information, this article summarizes one common scenario: see the SSL
specification for the full range of possibilities.
Note
Once an SSL session has been established it may be reused, thus avoiding
the performance penalty of repeating the many steps needed to start a
session. For this the server assigns each SSL session a unique session
identifier which is cached in the server and which the client can use on
forthcoming connections to reduce the handshake (until the session
identifer expires in the cache of the server).
--end quote--
url: http://www.modssl.org/docs/2.8/ssl_intro.html
> Solution description
> Replacing sendRedirect with request.forward function. This seems to keep
> the forwarding inside of tomcat.
Sometimes internal and external redirects are interchangable. Sometimes the
interchange is clumsy. Sometimes (two different web applications) impossible.
Nix.
--
To unsubscribe, e-mail: <mailto:tomcat-user-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: <mailto:tomcat-user-help@;jakarta.apache.org>
