Preflight response returns headers
server: uvicorn
access-control-allow-origin: *
access-control-allow-methods: DELETE, GET, HEAD, OPTIONS, PATCH, POST, PUT
access-control-max-age: 600
access-control-allow-headers: Accept, Accept-Language, Content-Language, Content-Type
content-length: 2
content-type: text/plain; charset=utf-8
for request with headers
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Firefox/102.0
Accept: */*
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Access-Control-Request-Method: PATCH
Access-Control-Request-Headers: content-type
Referer: http://localhost:8080/
Origin: http://localhost:8080
Connection: keep-alive
Sec-Fetch-Dest: empty
Sec-Fetch-Mode: cors
Sec-Fetch-Site: same-site
But Firefox (102.0) rejects this with reason CORS Method Not Found.
POST and DELETE methods work fine, only PATCH is rejected. In Chrome, this request passes without problems.
In FastAPI, I have a middleware configured as following:
middleware=[Middleware(CORSMiddleware, allow_origins=["*"], allow_methods=["*"])],
Does anyone know what the problem may be? I also don't send any content/data in this PATCH request, I don't know if that's important.
Related
when investigating network behavior, I usually use postman for sending HTTP requests, however
I need the option to send a raw HTTP request (via clear text), or at least only the headers, and it seems that postman does not support to edit your request via clear HTTP text. (buy the way the opposite is possible, you can read the raw http text of the requests you constructed in postman but you can't edit them)
for example:
Accept: text/javascript, text/html, application/xml, text/xml, */*
Accept-Encoding: gzip, deflate, br
Accept-Language: he-IL,he;q=0.9,en-US;q=0.8,en;q=0.7
Cache-Control: no-cache
Connection: keep-alive
Content-Length: 21114
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
Cookie: csrftoken=0alLaljTasofjCWZv7gcmukXuz6gMxfzlWpV691hzZZ1hTBcdVJ3mH8ozRDnO6hu; tk_or=%22%22; tk_lr=%22%22; session_id_12211=ff6a58b0baf98005748ce5a3c6a732aef33b750f; splunkweb_csrf_token_12211=10024448868272708216; token_key=10024448868272708216; experience_id=4852e1c6-726b-1ab3-bafa-f0a735d3f708; splunkd_12211=NjcrwAj_TLgz5JalVh2HTynLdbp_CPnfHFKi8qmsODiH40HI2urbPvAvJ9uvDKKoM3nATXEkS6dGytD0TvfiOtAUGJhk7Od25on_gJcZrQwcePQZ8HQaCmGScm^RXmOdDa^KVvN
Host: localhost:12211
Origin: http://localhost:12211
Pragma: no-cache
sec-ch-ua: "Chromium";v="106", "Google Chrome";v="106", "Not;A=Brand";v="99"
sec-ch-ua-mobile: ?0
sec-ch-ua-platform: "Windows"
Sec-Fetch-Dest: empty
Sec-Fetch-Mode: cors
Sec-Fetch-Site: same-origin
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/106.0.0.0 Safari/537.36
X-Requested-With: XMLHttpRequest
X-Splunk-Form-Key: 10024448898272708216
does postman allow editing the raw HTML? if not, there is other tool that can?
below link gives scanned list of stocks based on certain conditions
https://chartink.com/screener/mwdbscans
i can see that below is the url i should use for POST request
https://chartink.com/screener/process
i am facing problem when i want to send a POST request to get the list in python
from the developer tools, i could see the request headers and form data but when i encode the data and send the POST request i get error 500 (internal server error)
the data body of POST request i tried is,
Host: chartink.com
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:61.0)
Gecko/20100101 Firefox/61.0
Accept: application/json, text/javascript, */*; q=0.01
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate, br
Referer: https://chartink.com/screener/nsk-ohl-long
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
X-CSRF-TOKEN: PsJC0BUBkL7gE8YyglD6uYU8TpjqXLvN3whpdM9v
X-Requested-With: XMLHttpRequest
Content-Length: 179
Cookie: _ga=GA1.2.1391629072.1532845865; XSRF-
Connection: keep-alive
This is because mismatch of send data and the server side deserialize. you should send data from correct form to the server side. then server will be able to deserialise your data correctly.
I'm having a problem setting a content-type of application/json header on my post request.
saveUpdates(alltabs: AllTabs): Observable<Response> {
let api = this.host + this.routes.save;
let headers = new Headers();
headers.append('Content-Type', 'application/json');
return this._http.post(api, JSON.stringify(alltabs), { headers: headers })
.map((response: Response) => <Response>response.json())
.do(data => console.log("saveUpdates(): " + data))
.catch(this.handleError);
}
Request Headers:
OPTIONS /api/productsave HTTP/1.1
Host: wbtest:92
Connection: keep-alive
Pragma: no-cache
Cache-Control: no-cache
Access-Control-Request-Method: POST
Origin: http://localhost:3000
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.84 Safari/537.36
Access-Control-Request-Headers: content-type
Accept: */*
Referer: http://localhost:3000/product/60000010080
Accept-Encoding: gzip, deflate, sdch
Accept-Language: en-US,en;q=0.8
Response Headers:
HTTP/1.1 405 Method Not Allowed
Cache-Control: no-cache
Pragma: no-cache
Allow: POST
Content-Type: application/json; charset=utf-8
Expires: -1
Server: Microsoft-IIS/7.5
X-AspNet-Version: 4.0.30319
X-Powered-By: ASP.NET
Access-Control-Allow-Origin: *
Date: Tue, 14 Jun 2016 15:16:15 GMT
Content-Length: 76
As you can see, my request has two unexpected headers added "Access-Control-Request-Headers" and "Access-Control-Request-Method". This seems to suggest an issue with CORS (Cross-Origin Resource Sharing). However, the web.conf file on the API server has been working and the response headers states "Access-Control-Allow-Origin: *".
Any idea what could be wrong?
UPDATE:
The above code is correct - the problem is with the Sever code not being configured to handle preflight requests. In my case, the .NET Web API 2 application was not configured to allow CORS.
With CORS, you have two kinds of requests. As a matter of fact, the CORS specification distinguishes two distinct use cases:
Simple requests. This use case applies if we use HTTP GET, HEAD and POST methods. In the case of POST methods, only content types with the following values are supported: text/plain, application/x-www-form-urlencoded and multipart/form-data.
Preflighted requests. When the "simple requests" use case doesn't apply, a first request (with the HTTP OPTIONS method) is made to check what can be done in the context of cross-domain requests.
It seems that your server isn't configured to support preflighted request. The reason for the 405 status code (405 Method Not Allowed).
See this article for more details:
http://restlet.com/blog/2015/12/15/understanding-and-using-cors/
I have enabled Cross-Origin Resource Sharing (CORS) for my REST APIs (developed using ASP.NET Web API technology) by installing the necessary nuget package and calling config.EnableCors() in my web api configuration class.
This singular change seems to have worked when I tried making a cross site call to the application running on my localhost from another ordinary html site on the localhost as well which was failing previously due to the single origin restriction.
Now having deployed this update to the production test environment, it seems not to be working. Almost pulling out all my hairs here looking for a solution. Maybe someone can help me identify something I have missed.
Have you tagged your controllers with the EnableCors attribute?
e.g. from Enabling Cross-Origin Requests in ASP.NET Web API 2
using System.Net.Http;
using System.Web.Http;
using System.Web.Http.Cors;
namespace WebService.Controllers
{
[EnableCors(origins: "http://mywebclient.azurewebsites.net", headers: "*", methods: "*")]
public class TestController : ApiController
{
// Controller methods not shown...
}
}
I have the same problem.
Use this tool to investigate:
https://www.test-cors.org
https://www.test-cors.org/#?client_method=GET&client_credentials=true&client_headers=X-Api-Version%3A%202.0&server_url=http%3A%2F%2Falfa.jobit.io&server_enable=true&server_status=200&server_credentials=true&server_methods=POST%2C%20GET%2C%20OPTIONS&server_headers=X-Api-Version&server_tabs=local
No solution yet !
Options are sent but no actual request. Here is how it looks like in Wireshark:
I spent more than 50 hours learning about CROSS. Until I realizad localhost behave differently.
Preflight is used once I add custom headers (in this case api-version).
On both localhost and production, prelight returns successful. I am still investigating and I will complete this answer when solved.
Here are my headers for successfull CROSS with the server running on localhost:
############ Request Headers (OPTIONS) ############
=== Request Details ===
Access-Control-Request-Method: GET
Origin: http://alfa.example.io
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.20 Safari/537.36
Access-Control-Request-Headers: api-version
Accept: */*
############ Response Headers (Get) ############
=== Request Details ===
Connetion: Close
Date: Mon, 29 Oct 2018 19:50:40 GMT
Content-Type: application/json
Server: Kestrel
Transfer-Encoding: identity
Content-Encoding: identity
Access-Control-Allow-Credentials: true
Access-Control-Allow-Headers: api-version, Accept-Encoding, Accept-Language, User-Agent, Host, Connection, Authorization, timezone, X-CSRF-Token, Origin, X-Requested-With, Accept, Content-Type, Accept-Version, Content-Length, Content-MD5, Date, X-Api-Version, X-File-Name
Access-Control-Allow-Methods: POST, GET, PUT, PATCH, DELETE, OPTIONS
Access-Control-Allow-Origin: http://alfa.example.io
Request-Context: appId=cid-v1:0bdcbef4-4877-4790-bf3a-93aa6498f4df
############ Request Headers (GET) ############
=== Request Details ===
Accept: application/json, text/plain, */*
Origin: http://alfa.example.io
api-version: 2.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.20 Safari/537.36
############ Request Finished (Options) ############
=== Request ===
Method: GET
URL: http://localhost:5000/contacts/register/23
=== XHR Headers ===
Pragma: no-cache
Access-Control-Request-Method: GET
Origin: http://alfa.example.io
Accept-Encoding: gzip, deflate, br
Host: localhost:5000
Accept-Language: en-GB,en-US;q=0.9,en;q=0.8
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.20 Safari/537.36
Accept: */*
Cache-Control: no-cache
Referer: http://alfa.example.io/?debug=&invitation=CB89EDA9-C305-464E-99A9-8AA861F44A6F
Connection: keep-alive
Access-Control-Request-Headers: api-version
############ Response Headers (Get) ############
=== Request Details ===
Date: Mon, 29 Oct 2018 19:50:40 GMT
Content-Type: application/json; charset=utf-8
Server: Kestrel
Cache-Control: no-cache
Pragma: no-cache
Transfer-Encoding: chunked
Expires: -1
Vary: Origin
Access-Control-Allow-Credentials: true
Access-Control-Allow-Headers: api-version, Accept-Encoding, Accept-Language, User-Agent, Host, Connection, Authorization, timezone, X-CSRF-Token, Origin, X-Requested-With, Accept, Content-Type, Accept-Version, Content-Length, Content-MD5, Date, X-Api-Version, X-File-Name
Access-Control-Allow-Methods: POST, GET, PUT, PATCH, DELETE, OPTIONS
Access-Control-Allow-Origin: http://alfa.example.io
Request-Context: appId=cid-v1:0bdcbef4-4877-4790-bf3a-93aa6498f4df
Api-Supported-Version: 2.0
############ Request Finished (GET) ############
=== Request ===
Method: GET
URL: http://localhost:5000/contacts/register/23
=== XHR Headers ===
Pragma: no-cache
Origin: http://alfa.example.io
Accept-Encoding: gzip, deflate, br
Host: localhost:5000
Accept-Language: en-GB,en-US;q=0.9,en;q=0.8
api-version: 2.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.20 Safari/537.36
Accept: application/json, text/plain, */*
Cache-Control: no-cache
Referer: http://alfa.example.io/?debug=&invitation=CB89EDA9-C305-464E-99A9-8AA861F44A6F
Cookie: _ga=GA1.1.2021313723.1538951960; __test=1; _gid=GA1.1.1427728347.1540763978
Connection: keep-alive
Despite what the title may suggest, this is not related to the common "preventing double post request" issue.
In my application, I add some data on outgoing HTTP traffic, and with some some websites, I randomly encounter an HTTP POST request that has a double-header, resulting in a server termination, as I assume the server doesn't understand the request and decides to cut me off. As the title says, I'm literally seeing two POST headers in a single request. This only happens when I append some custom HTTP fields to the header. For example, I came across this today when I followed a surveygizmo.com link, as seen in the trace at the bottom of this post.
I cannot understand if it's the browser that's doing something funky because it noticed I've modified some data, or it's something in my LSP application that causes this to happen.
When I debug my application, I only see the intercepted request the first time, which is when I inject the custom data. After that, I don't see the request anywhere except in Wireshark, so it's not like I can remediate the double headers by deleting the redundant data.
Things to note looking at the trace:
The data I'm appending is 'Custom-FieldN:'
Two almost-identical headers
Three double-CRLF's in one single request header (how is that possible?)
The Request:
POST http://www.surveygizmo.com/s3/1212345/Who-Are-You HTTP/1.1
Host: www.surveygizmo.com
Custom-Field1: UserNameBob
Custom-Field2: 2578291789
proxy-connection: keep-alive
Content-Length: 836
Cache-Control: max-age=0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Origin: http://www.surveygizmo.com
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.31 (KHTML, like Gecko) Chrome/26.0.1410.64 Safari/537.31
Content-Type: multipart/form-data; boundary=----WebKitFormBoundaryaQraA7ZABICMT6jO
Referer: http://www.surveygizmo.com/s3/1212345/Who-Are-You
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-GB,en;q=0.8,en-US;q=0.6,ja;q=0.4
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3
Cookie: sg-response-979523-1212345=0%3B1369154430_519ba37e477bc8.35524744%3B1369154430%3BPartial
POST http://www.surveygizmo.com/s3/1212345/Who-Are-You HTTP/1.1
Host: www.surveygizmo.com
Custom-Field1: UserNameBob
Custom-Field2: 2578291789
proxy-connection: keep-alive
Content-Length: 836
Cache-Control: max-age=0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Origin: http://www.surveygizmo.com
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.31 (KHTML, like Gecko) Chrome/26.0.1410.64 Safari/537.31
Content-Type: multipart/form-data; boundary=----WebKitFormBoundaryaQraA7ZABICMT6jO
Referer: http://www.surveygizmo.com/s3/1212345/Who-Are-You
accept-encoding: gzip,deflate
Accept-Language: en-GB,en;q=0.8,en-US;q=0.6,ja;q=0.4
Accept-Charset: ISO-8859-1,utf-8;q=0.7,*;q=0.3
Cookie: sg-response-979523-1212345=0%3B1369154430_519ba37e477bc8.35524744%3B1369154430%3BPartial
------WebKitFormBoundaryaQraA7ZABICMT6jO
Content-Disposition: form-data; name="sg_navchoice"