I am trying to upload an image to a finagle (netty) server. For the OPTIONS request I return the following:
curl -X OPTIONS http://localhost:8686/images -i
HTTP/1.1 200 OK
Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: POST
Browser (FireBug): http://s15.postimg.org/vtdzyfshn/Screen_Shot_2014_09_02_at_9_49_05_PM.png
The following POST request fails with
Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote
resource at http://localhost:8686/images. This can be fixed by moving the resource
to the same domain or enabling CORS.
FireBug 1 (Console): http://s30.postimg.org/9utq4ridt/Screen_Shot_2014_09_02_at_9_53_41_PM.png
FireBug 2 (Net Tab): http://s16.postimg.org/jyblxfcv9/Screen_Shot_2014_09_02_at_9_54_37_PM.png
FireBug 3 (Net Tab - POST): http://s14.postimg.org/e8czua2wh/Screen_Shot_2014_09_02_at_9_54_47_PM.png
Any idea what I am missing?
(I am using this upload script: http://www.extremecss.com/creating-asynchronous-file-upload-system-using-html5-file-api/
You have to return the CORS headers (Access-Control-Allow-Origin: *) within the response header to your POST as well, instead of just within the OPTIONS response.
Related
I trying to scraping data from this url:
https://rgis.mosreg.ru/v3/swagger/map/layer?SERVICE=GeoJSON&layer=34&bbox=37.51027598519073,55.58991,37.84716401480926,55.89414999999997&zoom=11
In web browser, if I visit main page https://rgis.mosreg.ru first (to get cookies), and next - go to this url - all works fine.
But when I trying to perform this request in Postman - its fault with 401 "Unautorized" error.
In Postman I use all same headers and cookies, like in web-browser, but it does not help.
All cookies and headers are synced with browser using Postman INTERCEPTOR
What I missing out?
Chrome screen with headers
Postman screen. Header "mojo" looks line auth header
The server seems to only accept HTTP/2 and reject HTTP/1.1 call. If you have curl compiled with http2 support, you can test this directly:
curl --http2 'https://rgis.mosreg.ru/v3/swagger/map/layer?SERVICE=GeoJSON&layer=34&bbox=37.51027598519073,55.58991,37.84716401480926,55.89414999999997&zoom=11'
Output
< HTTP/2.0 200
< server:nginx/1.19.5 (MOGT Edition # rgis-pub-app-01)
otherwise it returns 401
At the moment, you can't run this request in Postman, because Postman doesn't have http2 support yet
You can also test it with python using the httpx package (pip install httpx[http2]):
import httpx
import asyncio
url = 'https://rgis.mosreg.ru/v3/swagger/map/layer?SERVICE=GeoJSON&layer=34&bbox=37.51027598519073,55.58991,37.84716401480926,55.89414999999997&zoom=11'
r = httpx.get(url)
print(r.http_version)
print(r.status_code)
client = httpx.AsyncClient(http2=True)
async def get():
response = await client.get(url)
print(response.http_version)
print(response.status_code)
asyncio.run(get())
Output
HTTP/1.1
401
HTTP/2
200
I am attempting to get some headers sent from my server to my front end via a fetch request.
In the controller function, I am explicitly sending some headers like this:
exports.getItems = async (ctx) => {
ctx.set('Search-type', 'category');
};
In postman, when I make a get request to my server I get these headers:
Connection →keep-alive
Content-Length →6442
Content-Type →application/json; charset=utf-8
Date →Thu, 19 Apr 2018 16:10:54 GMT
Search-type →category
However, when I try to access the header in the fetch request from the front end, I can only log the Content-Type. How do I get Search-type from my fetch?
After some googling, I found this issue on github which seems very similar to mine. This led me to another github issue page with the suggestion that I need to 'expose some explicitly needed headers'.
In the koa/cors documentation, there is an option allowHeaders Access-Control-Allow-Headers what I want to know is, how do I expose the headers so I can get them on my front end?
In the response to the GET, in addition to adding the Access-Control-Allow-Origin response header, you also need to include the Access-Control-Expose-Headers: <comma-separated-list-of-headers> response header.
If that header isn't returned by the server, even though the headers are sent by the server to the browser, the browser blocks any non-standard headers from being accessed by JavaScript. So you can see Content-Type (because it's a 'standard' response header), but not Search-type.
Basically, you need to ensure that the server responds with this
Access-Control-Expose-Headers: Search-type
(in addition to any other CORS response headers, like Access-Control-Allow-Origin, of course).
< HTTP/1.1 405 Method Not Allowed
< Allow: POST, GET, OPTIONS, HEAD
< Content-Length: 0
< Date: Fri, 26 May 2017 12:05:36 GMT
< Server: myservername
Hi whenever i do a curl request to my application using HTTP TRACE method . The above response displays .
Can someone tell me the steps to hide the "Allow: POST, GET, OPTIONS, HEAD" and "Server: myservername" information. How to hide these two in my TOMCAT6
By default Tomcat automatically responds to TRACE requests with a status code 405 and the headers you showed.
To change this behaviour you can do the following:
Allow TRACE requests to reach your servlets. This is done by settings the allowTrace attribute to true on a connector: https://tomcat.apache.org/tomcat-5.5-doc/config/http.html#Common_Attributes
In your servlet detect and handle the TRACE request and the send only the headers you want to send.
I think you should not take so much attention about that.
You launched a HTTP request with the method TRACE.
The answer tells you that method TRACE is not supported (Status 405) and provides available and supported method in the header Allow : POST, GET, OPTIONS, HEAD
All of this is perfectly acceptable and seems like a normal behaviour.
About the Server header, you have some details here
I'm trying to follow the datastore API tutorial and this simple request (sent via Fiddler):
POST https://api.dropbox.com/1/datastores/get_or_create_datastore HTTP/1.1
User-Agent: Fiddler
Host: api.dropbox.com
Content-Length: 12
Authorization: Bearer [snipped]
dsid=default
always results in this error response:
HTTP/1.1 400 Bad Request
{"error": {"dsid": "Missing value"}}
The access token was created from the developer app console, and my test app has full dropbox permissions. Running the list_datastores API call succeeds and reports that I do have one datastore with a dsid of default.
I think you'll need a header of Content-Type: application/x-www-form-url-encoded, since you're sending form-encoded parameters.
I'm trying to add a user to a Github repository via their API, but I always get a 502 Bad Gateway error.
With curl I send a request like this (<...> replaced by a real owner, repo, etc.):
curl -i -H 'Authorization: token xxxxxxxxxx' -XPUT https://api.github.com/repos/<owner>/<repo>/collaborators/<username>
I also tried it with this url:
curl -i -H 'Authorization: token xxxxxxxxxx' -XPUT https://api.github.com/teams/<id>/members/<username>
As token I used a newly created Personal Access Tokens
But both times I get this back
HTTP/1.0 502 Bad Gateway
Cache-Control: no-cache
Connection: close
Content-Type: text/html
<html><body><h1>502 Bad Gateway</h1>
The server returned an invalid or incomplete response.
</body></html>
A GET on each URL works fine but a DELETE doesn't work either. So maybe it has to do with curl.
Quoting the reply from GitHub's support with changes in italic:
You're just getting trolled by HTTP and curl.
When you make a PUT request with no body, curl doesn't explicitly set a Content-Length header for that request. However, PUT requests with no Content-Length confuse servers and they respond in weird ways.
Can you please try explicitly setting the Content-Lenght header to 0, or supplying an empty body when making that request (so that curl can set the header for you)? You can accomplish that adding -d "" in your command.