Return-Path: X-Original-To: apmail-httpd-dev-archive@www.apache.org Delivered-To: apmail-httpd-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id EEBC4D6F9 for ; Fri, 13 Jul 2012 19:01:47 +0000 (UTC) Received: (qmail 29665 invoked by uid 500); 13 Jul 2012 19:01:47 -0000 Delivered-To: apmail-httpd-dev-archive@httpd.apache.org Received: (qmail 29605 invoked by uid 500); 13 Jul 2012 19:01:47 -0000 Mailing-List: contact dev-help@httpd.apache.org; run by ezmlm Precedence: bulk Reply-To: dev@httpd.apache.org list-help: list-unsubscribe: List-Post: List-Id: Delivered-To: mailing list dev@httpd.apache.org Received: (qmail 29596 invoked by uid 99); 13 Jul 2012 19:01:47 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 13 Jul 2012 19:01:47 +0000 X-ASF-Spam-Status: No, hits=-2.3 required=5.0 tests=RCVD_IN_DNSWL_MED,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of rainer.jung@kippdata.de designates 195.227.30.149 as permitted sender) Received: from [195.227.30.149] (HELO mailserver.kippdata.de) (195.227.30.149) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 13 Jul 2012 19:01:39 +0000 Received: from [195.227.30.209] (notebook-rj [195.227.30.209]) by mailserver.kippdata.de (8.13.5/8.13.5) with ESMTP id q6DJ1JEp006111 for ; Fri, 13 Jul 2012 21:01:19 +0200 (CEST) Message-ID: <50007075.30603@kippdata.de> Date: Fri, 13 Jul 2012 21:01:09 +0200 From: Rainer Jung User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/20120614 Thunderbird/13.0.1 MIME-Version: 1.0 To: dev@httpd.apache.org Subject: Re: Time for Apache httpd 2.4.3 ?? References: <0291F6E9-F1B4-410B-9863-B153F2DB18BB@jaguNET.com> <4FFCA946.3090900@gmx.de> <14A05995-2D5C-4CC3-88F0-2E58945FCB81@jaguNET.com> <4FFD3064.5010709@gmx.de> <3CC2B454-FE30-4A42-A3A7-5104AFA523C4@gbiv.com> <4FFE7012.7030903@gmx.de> <39A715D2-DEBD-4613-B52B-96487B2B42A4@jagunet.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit On 13.07.2012 18:02, Jim Jagielski wrote: > If these can be added somewhat quickly, I'm willing to fast-track > them into 2.4.3. I drafted a patch available at http://people.apache.org/~rjung/patches/httpd-trunk-status-codes-iana.patch Coments: - I didn't fix the indentation in include/httpd.h in order to keep the patch readable. Some of the new codes have a short description which is a bit longer than the longest one used up to now. - I didn't "fix" the old define named "HTTP_REQUEST_URI_TOO_LARGE" which should have been "HTTP_REQUEST_URI_TOO_LONG" since it is defined in a public header file - I included all changes proposed by Julian - there is a big gap of unused numbers between 208 and 226 which I filled with "unknown" as was done before due to the limitations in ap_index_of_response() (focus on performance there) - I added canned error strings for the new codes - I did not yet define new error documents. The new pages could be HTTP_PRECONDITION_REQUIRED 428 HTTP_TOO_MANY_REQUESTS 429 HTTP_REQUEST_HEADER_FIELDS_TOO_LARGE 431 HTTP_LOOP_DETECTED 508 HTTP_NETWORK_AUTHENTICATION_REQUIRED 511 Furthermore some other 4xx and 5xx codes already defined in httpd.h also have no error page: HTTP_PAYMENT_REQUIRED 402 HTTP_NOT_ACCEPTABLE 406 HTTP_PROXY_AUTHENTICATION_REQUIRED 407 HTTP_CONFLICT 409 HTTP_RANGE_NOT_SATISFIABLE 416 HTTP_EXPECTATION_FAILED 417 HTTP_UNPROCESSABLE_ENTITY 422 HTTP_LOCKED 423 HTTP_FAILED_DEPENDENCY 424 HTTP_UPGRADE_REQUIRED 426 HTTP_GATEWAY_TIME_OUT 504 HTTP_VERSION_NOT_SUPPORTED 505 HTTP_INSUFFICIENT_STORAGE 507 HTTP_NOT_EXTENDED 510 I guess that means defining ones for the new codes is not a must ... - I did not check, which of the new codes actually should change behaviour of the web server!! Regards, Rainer > On Jul 12, 2012, at 9:07 AM, Jim Jagielski wrote: > >> ++1! >> On Jul 12, 2012, at 2:34 AM, Julian Reschke wrote: >> >>> On 2012-07-11 19:15, Roy T. Fielding wrote: >>>> I don't know of any issues with 308, and Julian generally knows what >>>> he is doing with regard to HTTP. In general, we should consider >>> >>> Thanks :-) >>> >>>> the IANA registry to be authoritative unless it is a known bug, >>> >>> In which case we should fix the registry. >>> >>>> which means we should support everything in >>>> >>>> http://www.iana.org/assignments/http-status-codes/http-status-codes.xml >>> >>> Yes. If we want to get all of these in, I can open a separate ticket and provide another patch. >>> >>> Best regards, Julian