You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The work in #48 has introduced an error handler errors.py to provide more information to the calling client, previously we'd return None for each failed request.
As we know, there is more information in the HTTP response that we might be able to take advantage of. See the authorisation example below. This might provide more useful feedback for users.
Curl example for authorisation:
curl -v -X GET "Authorization: ApiKey test:test" -H "Content-Type: application/json" -d '{u'username': 'demo', u'path': 'U2FtcGxlVHJhbnNmZXJz', u'api_key': 'dne'}' 'http://127.0.0.1:62081/api/v2/location/2a3d8d39-9cee-495e-b7ee-5e629254934d/browse/'
* Rebuilt URL to: Authorization: ApiKey test:test/
* Port number ended with ' '
* Closing connection -1
curl: (3) Port number ended with ' '
* Trying 127.0.0.1...
* TCP_NODELAY set
* Connected to 127.0.0.1 (127.0.0.1) port 62081 (#0)
> GET /api/v2/location/2a3d8d39-9cee-495e-b7ee-5e629254934d/browse/ HTTP/1.1
> Host: 127.0.0.1:62081
> User-Agent: curl/7.55.1
> Accept: */*
> Content-Type: application/json
> Content-Length: 61
>
* upload completely sent off: 61 out of 61 bytes
< HTTP/1.1 401 UNAUTHORIZED
< Server: nginx/1.12.2
< Date: Fri, 02 Mar 2018 04:39:19 GMT
< Content-Type: text/html; charset=utf-8
< Transfer-Encoding: chunked
< Connection: keep-alive
< Vary: Accept-Language, Cookie
< X-Frame-Options: SAMEORIGIN
< WWW-Authenticate: Basic Realm="django-tastypie"
< Content-Language: en
<
* Connection #0 to host 127.0.0.1 left intact
NBHTTP/1.1 401 UNAUTHORIZED could provide the client with a response more useful than None or out of #PR48 an Invalid Response (ERR_INVALID_RESPONSE)
Similarly, by simplifying the response from the request handler, we also lose the opportunity to get more specific information from responses without DEBUG logging, e.g. for a reingest where the transfer is already in progress we see:
WARNING 2018-04-06 15:40:58 utils.py:48 POST Request to http://127.0.0.1:62081/api/v2/file/6b0d6839-eed5-4b17-ab68-521a98b73f1e/reingest/ returned 409 CONFLICT
DEBUG 2018-04-06 15:40:58 utils.py:49 Response: {"error": true, "message": "This AIP is already being reingested on {pipeline}", "status_code": 409}
INFO 2018-04-06 15:40:58 reingest.py:192 Reingest UUID to work with None
Invalid response from server, check amclient log
Status code and message ultimately more descriptive than Invalid response from server, check amclient log.
The text was updated successfully, but these errors were encountered:
ross-spencer
changed the title
Enhancement: Consider utilising HTTP status codes more effectively
Problem: Consider utilising HTTP status codes more effectively
Apr 6, 2018
ross-spencer
changed the title
Problem: Consider utilising HTTP status codes more effectively
Problem: Consider exposing status codes and response.text to calling functions
Apr 6, 2018
The work in #48 has introduced an error handler
errors.py
to provide more information to the calling client, previously we'd returnNone
for each failed request.As we know, there is more information in the HTTP response that we might be able to take advantage of. See the authorisation example below. This might provide more useful feedback for users.
Curl example for authorisation:
NB
HTTP/1.1 401 UNAUTHORIZED
could provide the client with a response more useful thanNone
or out of #PR48 an Invalid Response (ERR_INVALID_RESPONSE
)Similarly, by simplifying the response from the request handler, we also lose the opportunity to get more specific information from responses without DEBUG logging, e.g. for a reingest where the transfer is already in progress we see:
Status code and message ultimately more descriptive than
Invalid response from server, check amclient log
.The text was updated successfully, but these errors were encountered: