I'm setting up an app with some REST webservices, that respond with 200 or 201 according to the result of the request.
On the other hand, i'm developing a javascript web application that has to use this webservices, so i'm dealing with CORS in the server-side with nginx adding the proper headers to the response.
The problem as i can tell, is that when the service responds with 201, cors headers don't reach the client. The first thought was that it was a problem/restriction on browsers, but then i realized that nginx was not adding the cors headers in any response with 201 status code.
The nginx config i'm using is available at https://github.com/UPCnet/maxserver/blob/master/production/nginx.conf
Any clue? Please ask if you need any other information/details
Thanks!
nginx directive add_headers only work for a short list of status code, in which 201 it's not in..
Adding the headers_module and using it instead, allows to add custom headers to responses with 201 status
Related
We've spotted (in our error tracking tool) some http 400 issues while fetching some static files.
Also, there are logs in our API gateway regarding that it redirected the request to S3 which responded 400.
It's not our CDN neither our API gateway.
Why would S3 respond 400 to a static file?
We couldn't find anything exactly about it anywhere so far, but some general resources about 400 were pointing to issues with some HTTP header:
Malformed request syntax
If-Modified-Since
Amazon ALB 400 Request header or cookie too large
Kong 400 Request header or cookie too large
Since we couldn't manually reproduce that accessing our system, we started trying to fetch the static files with some unexpected headers using Postman.
We finally could quickly reproduce the issue by sending huge Cookies.
Our hypothesis is that, probably, Amazon S3's static website has some configuration that blocks requests with some specific long headers/cookies.
Once we couldn't find a way to configure that on S3, we've added a plugin to our API Gateway that when it was a static file request, it would remove the cookie before redirecting it to S3 (it wasn't required).
After that change, we've monitored our error tracking tool, and the occurrences of http 400 on static website dropped to 0.
Today I just got kind same case, my case reason is the cookie side is too big.
I'm trying to determine what a client should do with headers on receiving a 303 (See Other) from the server. Specifically, what should be done with the Authorization header that was sent on the initial request?
Here's the problem: the client makes a request to myserver.com (HTTP request method is not relevant here) and the server at myserver.com responds with a 303 and the Location header contains otherserver.com/some_resource/. Tools like Postman and curl will follow the redirect by passing all the same headers in the subsequent request to otherserver.com. I haven't found a way to make these tools drop the headers.
In the case I've described, sending the Authorization header to otherserver.com seems like a security risk: otherserver.com now knows my token and possibly what host it can be used on so now the token is compromised. This can also cause errors, depending on how the destination host is configured. In the case where the redirect is to another resources on the same host (ie, myserver.com) then the Authorization header will (probably) need to be sent, and because it's the same host nothing is compromised.
Effectively, in different situations it seems that the correct behaviour is different. The relevant section in the RFC does not address this issue. In developing my own API, I've written documentation telling API clients to drop the Authorization header on redirect to otherserver.com. However, based on mucking around with curl and Postman, it's not clear to me either (a) what the default behaviour is for a typical HTTP client library or (b) whether HTTP client libraries permit easy modification of the HTTP headers before following a 303 redirect. As a result, it's possible my suggestion isn't practical. I also know of no way for the server to instruct the client as to what it should do with headers on following the 303 redirect.
What should a HTTP client do with the headers when it follows a 303 redirect? Who is responsible for deciding whether to use the same headers on the redirect, the HTTP client or server?
You can argue that when sending the 303 with otherserver.com's Location, myserver.com trusted otherserver.com to handle your token. It could have sent the token in the background as well. From the client's perspective, the client trusts myserver.com to handle the token, store and verify it securely, etc. If myserver.com decides to send it on to otherserver.com, should the client override? In this case it can of course, but in general I don't think it should.
As an attacker does not control the response headers from myserver.com which is a legit resource, I think in general it is secure to send the token by default to the other server it specifies, maybe unless you have some good reason not to (say an explicit policy on the client).
I'm trying to retrieve 3 response headers (Rails Devise Auth Headers: uid, client, access-token) in every request to a Rails Server.
Using Postman (http client) it's working.
With OkHttp (java http client) the headers just don't show up in the client (i've checked using Wireshark).
When i'm in debug mode it just work...
The additional headers with postman are due to postman sending an Origin header and the server is replying with CORS headers, i.e. Access-Control-.... These headers are send within the normal HTTP header, i.e. not after the response.
But these access control headers are only relevant when the access is done from a browser because they control the cross origin behavior of XHR. Since you are not inside a browser they should be irrelevant for what you are doing. What is relevant are the body of the response and some of the other headers and here you'll find no differences. Also irrelevant should be if multiple requests are send within the same TCP connection (HTTP keep-alive done by postman) or with multiple connections (OkHttp) because each request is independent from the other and using the same TCP connection is only a performance optimization.
If you really want to get these special headers you should add an Origin header within you OkHttp request. See the OkHttp examples on how to add your own headers. But like I said: these access control headers should be irrelevant for the real task and there should be no need to get to these headers.
There is a property "config.batch_request_buffer_throttle" in the file "config/initializers/devise_token_auth.rb" of the Rails Project. We changed it from 5 seconds to 0 seconds.
It is a property to keep the current token available for that amount of time to the following requests.
As the original documentation: "Sometimes it's necessary to make several requests to the API at the same time. In this case, each request in the batch will need to share the same auth token. This setting determines how far apart the requests can be while still using the same auth token."
So when we did the request using Postman or in Java Debug the 5 seconds was running allowing Devise to generate new tokens then retrieve them to the client.
A JavaScript client that I have no control over is sending the incorrect HTTP request headers to my Web API services. More specifically, it's using a library that is sending an incorrect OData header.
Is there any way that I can intercept the HTTP request before it hits my services? Can I add/remove/update headers or query string info?
For instance, if I receive the following HTTP header:
GET /Some/API HTTP/1.1
Host: myhost.com:80
MaxDataServiceVersion: 2.0
I'd like to know how to modify it to the following before the OData libraries take over:
GET /Some/API HTTP/1.1
Host: myhost.com:80
MaxDataServiceVersion: 4.0
The header isn't incorrect. Your client expects an OData v2 service and even if you did manipulate the headers, it probably won't be able to understand the response from your server.
But you could use a simple HTTP proxy to rewrite the headers if you really want to try that route.
If you do that, make sure your OData server supports the Atom format because the OData JSON format changed completely between versions 2 and 4, so there's no way that JavaScript client will understand it. The Atom format changed as well, but if the client's parser is extremely lenient, it might work.
We have a shortcut service in my company which basically provides redirection of short aliases to full URLs. The server runs a simple http redirection (302) service which uses the Host request header to a do a lookup with a file system based datastore.
I have a Resful Web Applciation and all the GET requests are working ok however POST/PUT requests are not reaching to server.
Does 302 "Redirect" by default keep the original requested method or it gets overwritten with GET types?
The 302 is generally implemented as specified by 303. To keep the original method, use 307 instead.
See also 302 section of the HTTP status code definitions:
Note: RFC 1945 and RFC 2068 specify that the client is not allowed
to change the method on the redirected request. However, most
existing user agent implementations treat 302 as if it were a 303
response, performing a GET on the Location field-value regardless
of the original request method. The status codes 303 and 307 have
been added for servers that wish to make unambiguously clear which
kind of reaction is expected of the client.
The 303 specifies that the new location should be requested by GET. The 307 keeps the original method.
For 302, POST is always rewritten to GET. Other methods sometimes (depending on how broken the browser is, see http://greenbytes.de/tech/tc/httpredirects/).