1036268 - REST webservice should return http/404 for invalid methods

Status: RESOLVED FIXED

(Bugzilla :: WebService, defect)

Description

[:glob ✱]

split from bug 1036225:

Currently when requesting the root of the API, two things happen:

1. We get a 200 OK
2. We get an error message, so basically contradicting the "200 OK".


→ http GET https://bugzilla.mozilla.org/rest/

HTTP/1.1 200 OK
Access-control-allow-headers: origin, content-type, accept
Access-control-allow-origin: *
Content-Encoding: gzip
Content-Length: 103
Content-Type: application/json; charset=UTF-8
Date: Wed, 09 Jul 2014 02:10:51 GMT
Etag: OP4JGZUOG6nkYGeU9b7x2A
Server: Apache
Strict-transport-security: max-age=31536000; includeSubDomains
Vary: Accept-Encoding
X-Backend-Server: web3.bugs.scl3.mozilla.com
X-content-type-options: nosniff
X-frame-options: SAMEORIGIN
X-xss-protection: 1; mode=block

{
    "code": 32614, 
    "error": true, 
    "message": "A REST API resource was not found for 'GET /'."
}

Suggestion: Send back an error to the client.

If there is no representation then just say it. It doesn't forbid to explain why in the payload. 
http://tools.ietf.org/html/rfc7231#section-6.5.4

HTTP/1.1 404 Not Found
Content-Length: 103
Content-Type: application/json; charset=UTF-8

{
    "code": 32614, 
    "error": true, 
    "message": "A REST API resource was not found for 'GET /'."
}

Comment 1

[David Lawrence [:dkl]]

Attachment: 1036268_1.patch

Comment 2

[:glob ✱]

Comment on attachment 8453167 [details] [diff] [review]
1036268_1.patch

Review of attachment 8453167 [details] [diff] [review]:
-----------------------------------------------------------------

odd, i get http/400 from bmo, not http/200:

~$ wget -O- https://bugzilla.mozilla.org/rest/
--2014-07-10 14:04:17--  https://bugzilla.mozilla.org/rest/
Resolving bugzilla.mozilla.org (bugzilla.mozilla.org)... 63.245.215.80
Connecting to bugzilla.mozilla.org (bugzilla.mozilla.org)|63.245.215.80|:443... connected.
HTTP request sent, awaiting response... 400
2014-07-10 14:04:19 ERROR 400: (no description).

regardless returning http/404 for "not found" is the right thing to do, and this patch does exactly that :)

r=glob

Comment 3

[Karl Dubost💡 :karlcow]

(In reply to Byron Jones ‹:glob› from comment #2)
> odd, i get http/400 from bmo, not http/200:


hehe. Opened Bug #1036802 
Good catch.

Comment 4

[David Lawrence [:dkl]]

To ssh://[e-mail]/bugzilla/bugzilla.git
   f0f5194..1a76a89  master -> master

Comment 5

[Karl Dubost💡 :karlcow]

Byron,
This doesn't seem to be fixed. An invalid request still gives back a 200, instead of the appropriate error status code. See below an example where we receive a 200.


→ http --print hH GET 'https://bugzilla.mozilla.org/rest/product?ids=1559&ids=1961' 'Accept:application/json' 'Accept-Encoding:'

GET /rest/product?ids=1559&ids=1961 HTTP/1.1
Accept: application/json
Accept-Encoding: 
Host: bugzilla.mozilla.org
User-Agent: HTTPie/0.8.0

HTTP/1.1 200 
Access-control-allow-headers: origin, content-type, accept
Access-control-allow-origin: *
Content-Type: application/json; charset=UTF-8
Date: Wed, 27 Aug 2014 00:18:35 GMT
Etag: dhi5uAj3Zz+7PGnmjJWOCg
Server: Apache
Strict-transport-security: max-age=31536000; includeSubDomains
Transfer-Encoding: chunked
Vary: Accept-Encoding
X-Backend-Server: web5.bugs.scl3.mozilla.com
X-content-type-options: nosniff
X-frame-options: SAMEORIGIN
X-xss-protection: 1; mode=block

{
    "code": 32614, 
    "documentation": "http://www.bugzilla.org/docs/tip/en/html/api/", 
    "error": true, 
    "message": "A REST API resource was not found for 'GET /component'."
}

Comment 6

[:glob ✱]

(In reply to Karl Dubost :karlcow from comment #5)
> This doesn't seem to be fixed. An invalid request still gives back a 200,
> instead of the appropriate error status code. See below an example where we
> receive a 200.

it's hard to tell as there's a discrepancy between your quoted request and the response.
https://bugzilla.mozilla.org/rest/product?ids=1559&ids=1061 is a valid method, and should return http/200
however the error message in your response quotes /component

/rest/component correctly returns http/404 for me:

$ wget -O/dev/null https://bugzilla.mozilla.org/rest/component -S --header 'Accept:application/json'
  HTTP/1.1 404
  Date: Wed, 27 Aug 2014 08:12:06 GMT
  Server: Apache
  Etag: xYfrm/cl4esqVJ8uRMVv+Q
  Access-control-allow-headers: origin, content-type, accept
  X-xss-protection: 1; mode=block
  Access-control-allow-origin: *
  Strict-transport-security: max-age=31536000; includeSubDomains
  X-frame-options: SAMEORIGIN
  X-content-type-options: nosniff
  X-Backend-Server: web1.bugs.scl3.mozilla.com
  Vary: Accept-Encoding
  Keep-Alive: timeout=5, max=1000
  Connection: Keep-Alive
  Transfer-Encoding: chunked
  Content-Type: application/json; charset=UTF-8

and /rest/product correctly returns http/200:
$ wget -O/dev/null 'https://bugzilla.mozilla.org/rest/product?ids=1559&ids=1961' -S --header 'Accept:application/json'
  HTTP/1.1 200
  Date: Wed, 27 Aug 2014 08:13:57 GMT
  Server: Apache
  Etag: dhi5uAj3Zz+7PGnmjJWOCg
  Access-control-allow-headers: origin, content-type, accept
  X-xss-protection: 1; mode=block
  Access-control-allow-origin: *
  Strict-transport-security: max-age=31536000; includeSubDomains
  X-frame-options: SAMEORIGIN
  X-content-type-options: nosniff
  X-Backend-Server: web2.bugs.scl3.mozilla.com
  Vary: Accept-Encoding
  Keep-Alive: timeout=5, max=1000
  Connection: Keep-Alive
  Transfer-Encoding: chunked
  Content-Type: application/json; charset=UTF-8



if you think this requires more investigation, please file a new bug.

Comment 7

[Karl Dubost💡 :karlcow]

Sorry my bad… 
Bad cut and paste. :) And it's in fact the Bug #1036802 which still trigger the 200 when gzip is on.