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.

A 404 is intended to be delivered should an application resource cannot be located by the server, not when a search returns no results.

> 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>

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.

> 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".

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.

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".

> 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.

Closing in favor of <https://github.com/php/web-php/issues/694>.