Bug 55364 - plain HTTP spoken on SSL port returns HTTP0.9 + HTML + no Content-Type + wrong Status
Summary: plain HTTP spoken on SSL port returns HTTP0.9 + HTML + no Content-Type + wron...
Status: RESOLVED DUPLICATE of bug 50823
Alias: None
Product: Apache httpd-2
Classification: Unclassified
Component: mod_ssl (show other bugs)
Version: 2.2.22
Hardware: All All
: P2 normal (vote)
Target Milestone: ---
Assignee: Apache HTTPD Bugs Mailing List
Depends on:
Reported: 2013-08-06 01:40 UTC by Christoph Anton Mitterer
Modified: 2013-08-20 21:42 UTC (History)
0 users


Note You need to log in before you can comment on or make changes to this bug.
Description Christoph Anton Mitterer 2013-08-06 01:40:01 UTC

This may be related to bug #9488.

When I speak (plain) HTTP to a Port where SSL is expected the following response is given:

- HTTP 0.9
Kinda weird since this should be really dead... any reason for that?
Anyway... I could live with that.

- The following HTML is returned as body:
<title>400 Bad Request</title>
<h1>Bad Request</h1>
<p>Your browser sent a request that this server could not understand.<br />
Reason: You're speaking plain HTTP to an SSL-enabled server port.<br />
Instead use the HTTPS scheme to access this URL, please.<br />
<blockquote>Hint: <a href="https://localhost/"><b>https://localhost/</b></a></blockquote></p>
<address>Apache/2.2.22 (Debian) Server at <a href="mailto:lcg-admin@lists.lrz.de">localhost</a> Port 443</address>

- no content type is given so browsers will render this as plain text
=> bug, either set the content type or don't return HTML

- 200 OK Status is given back.
For sure this can't be OK... I'm not sure whether the SSL/TLS standards specify anything for that case... but I'd rather guess that *IF* anything is returned,... it should be the 400 mentioned also in the HTML.

But does/should mod_ssl actually return ANY HTTP at all, in that case?
Is there any RFC which specifies this?

Comment 1 Eric Covener 2013-08-06 01:57:42 UTC
HTTP 0.9 doesn't have a status line or response headers, and that's the most we're willing to do for a response to HTTP on an HTTPS report. If you have other requirments, open an enhancement.  

Please resolve or turn into an enhancement with some specific requirement.
Comment 2 Christoph Anton Mitterer 2013-08-06 17:37:58 UTC
Hi Eric.

I see...

Well... IMHO it's generally questionable, that when connecting to HTTPS and that fails, that one get's HTTP back.
Under bad circumstances (stupid checks, which don't recognise that SSL handshake failed) that content might be even "trusted"... (but of course that would be a security problem in such clients... not Apache).

Anyway... IMHO, either nothing should be returned at all (which I'd probably prefer), or a new enough HTTP versions should be used, so that _at least_ a HTTP Status could be set that things gone wrong.
And if the HTTP version is not new enough to set a Content-Type, plain text should be returned, not HTTP.

Anyway... as said.. I haven't looked up the RFCs whether they mandate any behaviour in that case... so the above is just what I'd do out of common sense.

Comment 3 Eric Covener 2013-08-06 19:16:58 UTC
working as designed, open an enhancement if you want to be able to suppress it or respond differently.
Comment 4 Stefan Fritsch 2013-08-07 21:51:15 UTC
this is fixed in 2.4.3 and 2.2.24

*** This bug has been marked as a duplicate of bug 50823 ***
Comment 5 Christoph Anton Mitterer 2013-08-20 21:42:44 UTC
Hi Stefan.

Since Eric suggested to open a separate request for enhancement, I did this just before and opened bug #55458, only to see your comment now...

What exactly was changed in 2.4.3 and 2.2.24?