php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login

go to bug id or search bugs for

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
Anyone can comment on a bug. Have a simpler test case? Does it work for you on a different platform? Let us know!
Just going to say 'Me too!'? Don't clutter the database with that please — but make sure to vote on the bug!
Your email address:
MUST BE VALID
Solve the problem:
13 + 26 = ?
Subscribe to this entry?

 
 [2014-04-03 19:24 UTC] chibisuke at web dot de 
Description:
------------
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.

Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2014-04-03 21:18 UTC] requinix@php.net
-Status: Open +Status: Wont fix
 [2014-04-03 21:18 UTC] requinix@php.net 
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 Apr 18 17:01:28 2024 UTC