php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #66856 Failed manpage lookups return 200 OK
Submitted: 2014-03-08 20:13 UTC Modified: 2022-09-02 16:44 UTC
From: eldmannen+php at gmail dot com Assigned: cmb (profile)
Status: Duplicate Package: Website problem
PHP Version: Irrelevant OS:
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.
(description)
Block user comment
Status: Assign to:
Package:
Bug Type:
Summary:
From: eldmannen+php at gmail dot com
New email:
PHP Version: OS:

 

 [2014-03-08 20:13 UTC] eldmannen+php at gmail dot com
Description:
------------
When you try look up something by typeing www.php.net/<something_here> then if the lookup fails it says not found but it still serves a HTTP status code of 200 OK which makes the web browser save the URL in its address bar history.

Instead return HTTP status code 404 when a lookup fails to find anything, this way request doesn't get saved in the address bar history.


Patches

Add a Patch

Pull Requests

Add a Pull Request

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2014-03-13 17:08 UTC] levim@php.net
A successful search isn't a 404. The fact that it is doing a search means it didn't find what you are looking for, though. Anyone else have any comments? Sending a 404 is really easy if that's what we want to do, I'm just not sure.
 [2014-03-13 17:09 UTC] levim@php.net
-Assigned To: +Assigned To: levim
 [2015-01-03 12:14 UTC] jacob@php.net
-Status: Assigned +Status: Closed
 [2015-01-03 12:14 UTC] jacob@php.net
A 404 is intended to be delivered should an application resource cannot be located by the server, not when a search returns no results.
 [2015-01-03 12:41 UTC] cmbecker69 at gmx dot de
> A 404 is intended to be delivered should an application resource
> cannot be located by the server, not when a search returns no
> results.

Correct. However, in this case the user doesn't intend to search.
Compare the respective behavior of php.net to Github[1] or
Wikipedia[2], for instance.

[1] <https://github.com/doesntexist>
[2] <http://en.wikipedia.org/wiki/Doesntexist>
 [2015-01-03 12:49 UTC] jacob@php.net
GitHub and Wikipedia's approach are slightly different to PHP.net in my opinion as they render a straight 404 whereas PHP.net returns result sets based on a list possible matches - so technically, the resource is found. If we return a 404, we are essentially telling the browser that the "search results functionality" isn't available.
 [2015-01-03 13:14 UTC] cmbecker69 at gmx dot de
> so technically, the resource is found.

IMHO, the *requested* resource is not found, for instance, when
<http://php.net/doesntexist> is requested.

> If we return a 404, we are essentially telling the browser that
> the "search results functionality" isn't available.

Note, that it is something different when you type "doesntexist"
in the searchbox. You may also compare the difference in the
"final" URI:
<http://php.net/manual-lookup.php?pattern=doesntexist&scope=quickref>
<http://php.net/manual-lookup.php?pattern=doesntexist&lang=en&scope=404quickref>

The value of the scope parameter already hints at a "404".
 [2015-01-03 14:21 UTC] eldmannen+php at gmail dot com
-Status: Closed +Status: Assigned
 [2015-01-03 14:21 UTC] eldmannen+php at gmail dot com
www.example.net/foo is a HTTP resource.
If you request a resource, and it is not found then it should return a 404.

That you do a search when requesting a resource which was not found is a different thing.

I request a resource.
The resource was not found.
The server should return 404.
The server may optionally assist me by performing a search, however that does not change the fact that the resource was not found.

When I entered www.example.net/foo, I did *not* peform a search, I requested a resource. If the resource was not found, it must return 404.

You are right that a search should not return 404, but I requested the resource /foo, I did not query /search?query=foo in which case you are right it should return a 200 OK.
 [2015-01-03 14:42 UTC] eldmannen+php at gmail dot com
Jacob,
> A 404 is intended to be delivered should an application resource cannot be located by the server, not when a search returns no results.

No, this is not limited to application resources. This is for any HTTP resource.
The HTTP protocol doesn't care what underlying mechanism handles the request, if it is a file on the file system or a application. A resource was requested, if the resource is not found, it should return 404.

It is true that 404 should not be returned upon a search which returns no results, however when you visit the resource example.net/foo you are *not* asking to perform a search, you are asking to retrieve a resource.


> GitHub and Wikipedia's approach are slightly different to PHP.net in my opinion as they render a straight 404 whereas PHP.net returns result sets based on a list possible matches - so technically, the resource is found.

No, the resource is not found. Instead you are served another page (which in this case performs a search).

> If we return a 404, we are essentially telling the browser that the "search results functionality" isn't available.
No, we are telling the browser "the resource you requested was not found, but there are some search results that might help you".
 [2015-01-04 20:45 UTC] jacob@php.net
> When I entered www.example.net/foo, I did *not* peform a search, I requested a
> resource. If the resource was not found, it must return 404.

I've reconsidered this and realised you are right. That page should definitely be returning a 404.
 [2022-09-02 16:44 UTC] cmb@php.net
-Status: Assigned +Status: Duplicate -Assigned To: levim +Assigned To: cmb
 [2022-09-02 16:44 UTC] cmb@php.net
Closing in favor of <https://github.com/php/web-php/issues/694>.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Tue Mar 19 04:01:31 2024 UTC