|  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Request #67013 make default status code configurable
Submitted: 2014-04-03 19:24 UTC Modified: 2014-04-04 05:33 UTC
From: chibisuke at web dot de Assigned:
Status: Wont fix Package: *Web Server problem
PHP Version: Irrelevant OS: all
Private report: No CVE-ID: None
View Add Comment Developer Edit
Welcome! If you don't have a Git account, you can't do anything here.
You can add a comment by following this link or if you reported this bug, you can edit this bug over here.
Block user comment
Status: Assign to:
Bug Type:
From: chibisuke at web dot de
New email:
PHP Version: OS:


 [2014-04-03 19:24 UTC] chibisuke at web dot de
Currently PHP sends a HTTP/200 Success Status code to the browser if it recived a CONNECT request. Game goes for webdav requests like PROPFIND, DELETE ect. 

Most scripts are not ment to handle this kind of requests, so it would make sense to allow modifying the default status code of such requests. 

For example in case of a CONNECT replying HTTP/200 is plain simply wrong unless in verify specific cases where PHP actually is proxying stuff. 

So I suggest to create ini directive which HTTP Status codes to reply by default. 
Any change by a user script can then happen using the header() function. 

as defaults I'd suggest to use HTTP/405 for CONNECT, anything else should return HTTP/200 for now. 

This default should later be changed to HTTP/405 for anything beside GET and POST once ppl had time to ajust their scripts. 


Add a Patch

Pull Requests

Add a Pull Request


AllCommentsChangesGit/SVN commitsRelated reports
 [2014-04-03 21:18 UTC]
-Status: Open +Status: Wont fix
 [2014-04-03 21:18 UTC]
You're free to go through the RFC process to propose this feature, but the basic response is

No thanks. For one, adding INI settings is strongly discouraged. One of the biggest reasons is the problem of portability: now code has to be aware of multiple possible configurations of an environment. It also adds more risk to installing and upgrading PHP as it's easy for settings to be missed; I, for one, frequently deal with people asking about why their application changed when their host upgraded PHP versions.

More significantly, this is totally something that should be addressed by a userland framework. Stock PHP does not do proxying or WebDAV or anything more complex than parsing request bodies and handling file uploads. Given that one already has to write code to support these other features, it's trivial to simply add a call to header() in an appropriate place.
 [2014-04-04 05:33 UTC] chibisuke at web dot de
The fact that one has to explicitly write code to support this is the reason I'm suggesting this change. 

If the code doesn't support it PHP should report this as "unsupported" (HTTP/405).
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Thu Feb 22 04:01:29 2024 UTC