Here's a situation we've faced. We store some media objects (AWS S3 backend) and the API returns temporary redirects with timestamped signature in the URL. The resource requires our custom token-based authentication (Authorization header in request).
The client-side (JS app) uses direct URLs to resources in tags like but it fails because of authentication. When using a XHR to perform authorised request the XHR follows redirect automatically (no chance to switch it off) and this one is also not an option.
The always200=true therefore is a good way to overcome this problem. But in this case the response from the server contain http status 200 and of course an empty body (originally we send a temporary redirect). Therefore it's nearly impossible to figure out what's happening on the server (without looking into the headers of course).
The question is would it be an expected behaviour from goweb to force to include a body, where it was not specified in cases with awlays200 to contain at least { s:REAL_STATUS} ?
Here's a situation we've faced. We store some media objects (AWS S3 backend) and the API returns temporary redirects with timestamped signature in the URL. The resource requires our custom token-based authentication (Authorization header in request). The client-side (JS app) uses direct URLs to resources in tags like
but it fails because of authentication. When using a XHR to perform authorised request the XHR follows redirect automatically (no chance to switch it off) and this one is also not an option.
The always200=true therefore is a good way to overcome this problem. But in this case the response from the server contain http status 200 and of course an empty body (originally we send a temporary redirect). Therefore it's nearly impossible to figure out what's happening on the server (without looking into the headers of course).
The question is would it be an expected behaviour from goweb to force to include a body, where it was not specified in cases with awlays200 to contain at least { s:REAL_STATUS} ?