Bug#701117: Fwd: Re: Bug#701117: Apache : Custom ErrorDocument 400 not working when Host header is missing
-------- Original Message --------
From: christophe@guilloux.info Fri Feb 22 00:16:41 2013
Return-Path: <christophe@guilloux.info>
X-Original-To: debian@toell.net
Delivered-To: debian@toell.net
Received: by smart.knallkopp.de (Postfix, from userid 6061) id
DBAA4164090; Fri, 22 Feb 2013 00:16:40 +0100 (CET)
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smart.knallkopp.de
X-Spam-Level: *
X-Spam-Status: No, score=1.3 required=3.0 tests=RDNS_NONE
autolearn=disabled version=3.3.1
X-policyd-weight: using cached result; rate: -5.5
Received: from master.debian.org (unknown [82.195.75.110]) (using TLSv1
with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate
requested) by smart.knallkopp.de (Postfix) with ESMTPS id 442F0164059
for <debian@toell.net>; Fri, 22 Feb 2013 00:16:39 +0100 (CET)
Received: from srv002.dedinux.com ([46.105.37.180]) by master.debian.org
with esmtp (Exim 4.80) (envelope-from <christophe@guilloux.info>) id
1U8fNW-0006tv-Tn for debian@toell.net; Thu, 21 Feb 2013 23:16:38 +0000
Received: from localhost (localhost.localdomain [127.0.0.1]) by
srv002.dedinux.com (Postfix) with ESMTP id 6A38E2C0579 for
<arno@debian.org>; Fri, 22 Feb 2013 00:16:33 +0100 (CET)
X-Virus-Scanned: spam & virus filtering at
Received: from srv002.dedinux.com ([127.0.0.1]) by localhost
(srv002.dedinux.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id
OzGGWBjbcLBs for <arno@debian.org>; Fri, 22 Feb 2013 00:16:33 +0100 (CET)
Received: from srv002.dedinux.com (localhost.localdomain [127.0.0.1]) by
srv002.dedinux.com (Postfix) with ESMTP id 085152C376C for
<arno@debian.org>; Fri, 22 Feb 2013 00:16:33 +0100 (CET)
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Date: Fri, 22 Feb 2013 00:16:33 +0100
From: Christophe GUILLOUX <christophe@guilloux.info>
To: Arno Töll <arno@debian.org>
Subject: Re: Bug#701117: Apache : Custom ErrorDocument 400 not working
when Host header is missing
In-Reply-To: <[🔎] 51268E3F.7090208@debian.org>
References: <[🔎] 0f6a07fa3ffe54e44a2738c4f5071d79@srv002.dedinux.com>
<[🔎] 51268E3F.7090208@debian.org>
Message-ID: <d800d1731c1c623625e05e6af1c6e7fb@srv002.dedinux.com>
X-Sender: christophe@guilloux.info
User-Agent: Roundcube Webmail/0.7.1
Le 2013-02-21 22:14, Arno Töll a écrit :
> On 21.02.2013 20:26, Christophe GUILLOUX wrote:
>> This bug is affecting debian wheezy, some browser can be affected
>> and
>> other not (because they interpret the page as a html by default) :
>> https://issues.apache.org/bugzilla/show_bug.cgi?id=48357
>
> I am not sure how your description matches the bug you mentioned. The
> bug you linked is about custom error page handling when clients
> violating the HTTP 1.1 protocol are requesting pages.
>
> Do you mind to explain?
Sorry, I don't understand the entire second sentence.
I think apache should respond with header even if the client sent a bad
request.
RFC is too long but i suppose they write that server must respond :
HTTP/1.1 400 Bad Request
...
and not directly the html or text.
For example, i do :
telnet alioth.debian.org 443
Trying 217.196.43.134...
Connected to alioth.debian.org.
Escape character is '^]'.
GET / HTTP/1.1
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>400 Bad Request</title>
</head><body>
<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://alioth.debian.org/";><b>https://alioth.debian.org/</b></a></blockquote></p>
<hr>
<address>Apache/2.2.16 (Debian) Server at alioth.debian.org Port
443</address>
</body></html>
Connection closed by foreign host.
I think it miss this before the html response:
HTTP/1.1 400 Bad Request
Date: Thu, 21 Feb 2013 23:13:29 GMT
Server: Apache/2.2.16 (Debian)
Vary: Accept-Encoding
Content-Length: 309
Connection: close
Content-Type: text/html; charset=iso-8859-1
It seems that the problem appear only when client do a clear request on
a SSL port.
--
Cordialement,
Christophe GUILLOUX
Reply to: