Bug 51603

Please provide your logging configuration.

The logging configuration is the default logging configuration; I have changed nothing:

#
# LogLevel: Control the number of messages logged to the error_log.
# Possible values include: debug, info, notice, warn, error, crit,
# alert, emerg.
#
LogLevel warn

<IfModule log_config_module>
    #
    # The following directives define some format nicknames for use with
    # a CustomLog directive (see below).
    #
    LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\"" combined
    LogFormat "%h %l %u %t \"%r\" %>s %b" common

    <IfModule logio_module>
      # You need to enable mod_logio.c to use %I and %O
      LogFormat "%h %l %u %t \"%r\" %>s %b \"%{Referer}i\" \"%{User-Agent}i\" %I %O" combinedio
    </IfModule>

    #
    # The location and format of the access logfile (Common Logfile Format).
    # If you do not define any access logfiles within a <VirtualHost>
    # container, they will be logged here.  Contrariwise, if you *do*
    # define per-<VirtualHost> access logfiles, transactions will be
    # logged therein and *not* in this file.
    #
    CustomLog "logs/access.log" common

    #
    # If you prefer a logfile with access, agent, and referer information
    # (Combined Logfile Format) you can use the following directive.
    #
    #CustomLog "logs/access.log" combined
</IfModule>

> I'd really like to know what data it is sending across the wire

Can you capture and post what the response is?

I have checked the file sizes against the known website files and it appears that Apache returns the root item (GET /), in my case index.php, to the client.  So no security issue, just weird behavior.  I guess Apache should reject all malformed HTTP requests rather than returning the root item.

I haven't looked, but is it mod_ssl returning the speaking-non-SSL-on-SSL-port message?

Hmm, I tried opening the URL as http://www.archangel.dk (the website), https://www.archangel.dk (shouldn't be open as the firewall blocks it) and https://www.archangel.dk:80.  The last attempt gave this result:

90.185.163.243 - - [03/Aug/2011:22:53:18 +0200] "\x16\x03\x01" 200 1279
90.185.163.243 - - [03/Aug/2011:22:53:18 +0200] "\x16\x03\x01" 200 1279

I simply don't know enough HTTPS and HTTP to say whether it is really an error or just somebody hammering on my website using SSL on port 80, which could possibly explain the "bizarre" reaction by Apache that I am seeing.

I can say that mod_ssl is not loaded.

I don't know if there's really a problem at all or if it is just me being hyper-aggressive over somebody probing my website with SSL packets on port 80.

Please help us to refine our list of open and current defects; this is a mass update of old and inactive Bugzilla reports which reflect user error, already resolved defects, and still-existing defects in httpd.

As repeatedly announced, the Apache HTTP Server Project has discontinued all development and patch review of the 2.2.x series of releases. The final release 2.2.34 was published in July 2017, and no further evaluation of bug reports or security risks will be considered or published for 2.2.x releases. All reports older than 2.4.x have been updated to status RESOLVED/LATER; no further action is expected unless the report still applies to a current version of httpd.

If your report represented a question or confusion about how to use an httpd feature, an unexpected server behavior, problems building or installing httpd, or working with an external component (a third party module, browser etc.) we ask you to start by bringing your question to the User Support and Discussion mailing list, see [https://httpd.apache.org/lists.html#http-users] for details. Include a link to this Bugzilla report for completeness with your question.

If your report was clearly a defect in httpd or a feature request, we ask that you retest using a modern httpd release (2.4.33 or later) released in the past year. If it can be reproduced, please reopen this bug and change the Version field above to the httpd version you have reconfirmed with.

Your help in identifying defects or enhancements still applicable to the current httpd server software release is greatly appreciated.