Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:116727 Return-Path: Delivered-To: mailing list internals@lists.php.net Received: (qmail 2537 invoked from network); 23 Dec 2021 14:36:26 -0000 Received: from unknown (HELO php-smtp4.php.net) (45.112.84.5) by pb1.pair.com with SMTP; 23 Dec 2021 14:36:26 -0000 Received: from php-smtp4.php.net (localhost [127.0.0.1]) by php-smtp4.php.net (Postfix) with ESMTP id E25861804BA for ; Thu, 23 Dec 2021 07:40:39 -0800 (PST) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on php-smtp4.php.net X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_ENVFROM_END_DIGIT, FREEMAIL_FROM,HTML_MESSAGE,MISSING_HEADERS,RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.2 X-Spam-ASN: AS15169 209.85.128.0/17 X-Spam-Virus: No X-Envelope-From: Received: from mail-pj1-f48.google.com (mail-pj1-f48.google.com [209.85.216.48]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by php-smtp4.php.net (Postfix) with ESMTPS for ; Thu, 23 Dec 2021 07:40:39 -0800 (PST) Received: by mail-pj1-f48.google.com with SMTP id gj24so5407792pjb.0 for ; Thu, 23 Dec 2021 07:40:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:cc; bh=GxwHrY5uv62PADUHNV371vrRa94LShb8TEUQHnMlzQ8=; b=VzYUUFzd3xiu4Yex0BMTBTQ1gKNfed2axii63TvstAQ5DPZxTvPOPSzTo4zDdpODlJ aLuLLOfYm4CPFPPYFPiSDQu9EBGT/FGytpPW8UyPryaJEeEup9oXkxG/5iPC9IZT/Zhz RliGjJNpxyMkdJY9hZZV3Rjo78ZvdFY0yP/J1z2KvqL38R8psIRDwrldCPzhWJs9qcAK 8por+HFLeW20/m8QNrG024O7yi2TcntxeHsdlzbHH+b5ZJb04RkTkxvHwYEZRxddQtQm jpzYvtrD4+ZyeN8L/yn100I9XWNn1XCdrXDt5hs+xDoo4u0QvArxBnETPQ0pMb+lLji2 liCg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:cc; bh=GxwHrY5uv62PADUHNV371vrRa94LShb8TEUQHnMlzQ8=; b=C5phrs7SI81iSG77uodfis96zSKj4fWOowId4Kfr3LMsa54HfohdVIBHbmQgg0xG9b /zg4utiCR5Jtx83TYwR0OPT8oIfFwS2B5Z20WQjMDIZ/p/YMbLoSUXRAsAdob62t809L q/AOgrLjXY2HV0e6tnfLibDSEtn8TPaA0A3pc8gakcb941HFvSW+pSu17I7IQac67hLt IDfkM/lhuPWglrd4QQ4+mrmH9q7Vi1XwnrQ5/p81a1yynZsv/YDZefvI58mHol6jjTkZ gbTTc0ozcXkmVsGMaaQQb6XFNu6E3qZDFrGgtxoDs2g9z6YUBcTCSyb7lc9JqoIatGx4 I4BA== X-Gm-Message-State: AOAM530nF4IAvwjBJtNEv4Gxxtx90G7FwBndtY5qttBzvBNv7/FAurk6 dJyOIWY+Jj4yMIRKQuzgjM+njNY5k8QlqMeC28qiZPHBw3s= X-Google-Smtp-Source: ABdhPJzl0Tj0X558lhBvFpCVK8frRqAUyuNGl/eQStbTrSuxpMENro283Mrlqxxr+Yad7xBW87swdWXEhw5M3pqT8Bc= X-Received: by 2002:a17:90b:1b06:: with SMTP id nu6mr2918786pjb.213.1640274037792; Thu, 23 Dec 2021 07:40:37 -0800 (PST) MIME-Version: 1.0 References: <5d2b1d8f-9b7a-558f-8750-cc97b3ad0589@gmx.de> In-Reply-To: Date: Thu, 23 Dec 2021 16:40:01 +0100 Message-ID: Cc: PHP internals Content-Type: multipart/alternative; boundary="0000000000005b651105d3d20f34" Subject: Re: [PHP-DEV] header() allows arbitrary status codes From: divinity76@gmail.com (Hans Henrik Bergan) --0000000000005b651105d3d20f34 Content-Type: text/plain; charset="UTF-8" sometime in the future HTTP 6xx will be defined, and we'll have to add a big warning to the header()/http_respons_code() pages like "Warning: HTTP 6.x.x is only supported in PHP >= x.x.x and PHP <=8.1.x", and library developers have to add fugly code like `if(PHP_VERSION_MAJOR >= X || (PHP_VERSION_MAJOR <=8 && PHP_VERSION_MINOR <= 1){http_response_code(6xx);}else{ trigger_error("your php version cannot use http 6xx"); } i'd prefer if we didn't restrict the header ranges On Thu, 23 Dec 2021 at 13:47, Paul Dragoonis wrote: > On Thu, 23 Dec 2021, 00:06 David Gebler, wrote: > > > On Tue, Dec 21, 2021 at 6:59 PM Christoph M. Becker > > wrote: > > > > > Hi all, > > > > > > a while ago it has been reported[1] that our header() function actually > > > allows arbitrary status codes, which may even overflow. Of course, > that > > > makes no sense, since the status code is supposed to be a three digit > > > code. So this ticket has been followed up by a pull request[2], and > > > Jakub suggested to further restrict the status code to be in range 100 > - > > > 599. > > > > > > > Personally, I don't like restricting the status code to a number in the > > 100-599 range. As far as I know, RFC 7230 doesn't mandate anything beyond > > the requirement of 3 digits and while 7231 may only specify semantics for > > 1xx-5xx, that doesn't mean there isn't a legitimate use-case in custom or > > internal applications for status codes outside the usual semantics. > > > > The overflow part is a legit bug which can and should be fixed, but I'd > at > > least question whether a user should be obliged to stick to conventional > > HTTP semantics via the header() function, or even a strictly conformant > > implementation of the standards defined 7320. Maybe this behaviour could > be > > default but overridable via a new, fourth optional parameter or > something, > > I don't know...but I can easily imagine someone having a legitimate > context > > in which they want to send status codes outside the usual range > > representing custom semantics. > > > > > I think its safe to say we should restrict the overflow parts. > > As for boundaries; I don't know who is or isn't using their own custom > status codes. It's unlikely, but entirely possible. As such, this is > considered a BC break. > > If we apply restrictions to a minor release, then upgrading will be harder > for 8.2 if we include this in the next release. > > You could say 98% of people are using standard ranges for status codes, but > we do have to always take into account the 2% on our decisions. > > Thanks. > > > > > > > > > > > > Since this could break some pathological cases, I wanted to ask whether > > > anybody objects to this change for the master branch (i.e. PHP 8.2). > > > > > > [1] > > > [2] > > > > > > Christoph > > > > > > -- > > > PHP Internals - PHP Runtime Development Mailing List > > > To unsubscribe, visit: https://www.php.net/unsub.php > > > > > > > > > --0000000000005b651105d3d20f34--