Survey JS long loading times status code 302 - javascript

I am trying to load survey.jquery.min.js and it is taking a long time. Is this something that I am doing wrong when calling it or is it a survey js issue?
Called before </body>
<script type="text/javascript" src="https://unpkg.com/survey-jquery/survey.jquery.min.js"></script>
Http header com/survey-jquery/survey.jquery.min.js
Request Method: GET
Status Code: 302
Remote Address: [2606:4700::6810:7aaf]:443
Referrer Policy: strict-origin-when-cross-origin
access-control-allow-origin: *
cache-control: public, s-maxage=600, max-age=60
cf-cache-status: EXPIRED
cf-ray: 79a7e93c7ac371cf-LHR
content-type: text/plain; charset=utf-8
date: Thu, 16 Feb 2023 17:13:18 GMT
fly-request-id: 01GSDKE0EQKG6989ZPSPDXG931-lhr
location: /survey-jquery#1.9.74/survey.jquery.min.js
server: cloudflare
strict-transport-security: max-age=31536000; includeSubDomains; preload
vary: Accept, Accept-Encoding
via: 1.1 fly.io
x-content-type-options: nosniff
:authority: unpkg.com
:method: GET
:path: /survey-jquery/survey.jquery.min.js
:scheme: https
accept: */*
accept-encoding: gzip, deflate, br
accept-language: en-US,en;q=0.9
sec-ch-ua: "Chromium";v="110", "Not A(Brand";v="24", "Google Chrome";v="110"
sec-ch-ua-mobile: ?0
sec-ch-ua-platform: "Windows"
sec-fetch-dest: script
sec-fetch-mode: no-cors
sec-fetch-site: cross-site
user-agent: Mozilla/5.0
I have tried to load the page on different devices and network to rule them out as possible issues.

Related

Fetch request failing for DELETE method even though CORS headers are present

I am trying to make a Cross Origin delete request via fetch and its failing with a 403 (Exact Error Access to fetch at 'http://localhost:1180/api/deleteResource/name/something/city/Shenzhen%202' from origin 'http://localhost:3000' has been blocked by CORS policy: Response to preflight request doesn't pass access control check: It does not have HTTP ok status.)
Here are my request and response headers -
General -
Request URL: http://localhost:1180/api/deleteResource/name/something/city/Shenzhen%202
Request Method: OPTIONS
Status Code: 403 FORBIDDEN
Remote Address: [::1]:1180
Referrer Policy: no-referrer-when-downgrade
Response Headers-
Access-Control-Allow-Credentials: false
Access-Control-Allow-Headers: Content-Type,Content-Length,Server,Date
Access-Control-Allow-Methods: GET, HEAD, POST, PUT, DELETE, CONNECT, OPTIONS, TRACE, PATCH
Access-Control-Allow-Origin: *
Access-Control-Expose-Headers: Content-Type, Content-Length, Server, Date
Content-Length: 43
Content-Type: application/json
Content-Type: application/json; charset=utf-8
Date: Mon, 18 Nov 2019 07:24:51 GMT
Server: Werkzeug/0.14.1 Python/3.6.5
X-Content-Type-Options: nosniff
Request headers-
Accept: */*
Accept-Encoding: gzip, deflate, br
Accept-Language: en-US,en;q=0.9
Access-Control-Request-Headers: access-control-allow-methods,access-control-allow-origin
Access-Control-Request-Method: DELETE
Connection: keep-alive
Host: localhost:1180
Origin: http://localhost:3000
Referer: http://localhost:3000/
Sec-Fetch-Mode: cors
Sec-Fetch-Site: same-site
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.97 Safari/537.36
Whereas my GET requests are working just fine -
General -
Request URL: http://localhost:1180/api/getResources
Request Method: GET
Status Code: 200 OK
Remote Address: [::1]:1180
Referrer Policy: no-referrer-when-downgrade
Response Headers -
Access-Control-Allow-Credentials: false
Access-Control-Allow-Headers: Content-Type,Content-Length,Server,Date
Access-Control-Allow-Methods: GET, HEAD, POST, PUT, DELETE, CONNECT, OPTIONS, TRACE, PATCH
Access-Control-Allow-Origin: *
Access-Control-Expose-Headers: Content-Type, Content-Length, Server, Date
Content-Length: 6164
Content-Type: application/json
Content-Type: application/json; charset=utf-8
Date: Mon, 18 Nov 2019 07:24:44 GMT
Server: Werkzeug/0.14.1 Python/3.6.5
X-Content-Type-Options: nosniff
Request Headers -
Accept: */*
Accept-Encoding: gzip, deflate, br
Accept-Language: en-US,en;q=0.9
Connection: keep-alive
Host: localhost:1180
Origin: http://localhost:3000
Referer: http://localhost:3000/
Sec-Fetch-Mode: cors
Sec-Fetch-Site: same-site
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_14_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.97 Safari/537.36
I do understand that the preflight check doesn't happen for Simple GET & POST requests due to which my GET is successful, but still I don't get why my DELETE is failing as it has been allowed from the server. Can someone help me understand what the problem here is?
Your DELETE request has access-control-allow-methods,access-control-allow-origin headers, But In response, It only allows Content-Type, Content-Length, Server, Date headers. That's why it's throwing doesn't pass access control error.
Solution
Set Access-Control-Allow-Headers to allow Content-Type,Content-Length,Server,Date,access-control-allow-methods,access-control-allow-origin.
I am not sure about your Back-End technology, I can't provide code to allow above headers without knowing your back-end technology

Authorization header when following redirects

When following redirects for a 303 response, in a Chrome, IE, and Firefox, the Authorization header is included.
That's an issue when a request to an internal service respond with a signed S3 URL in the Location header.
S3 will respond with a 400 response, and can't figure out which authentication method to use.
Request to internal service
GET INTERNAL_SERVICE HTTP/1.1
Pragma: no-cache
Origin: https://example.com
Accept-Encoding: gzip, deflate, br
Accept-Language: en-GB,en;q=0.9,en-US;q=0.8,da;q=0.7,de;q=0.6
Authorization: Bearer g6YQjOy3BDu32es8xKdMRNpcQ2Fkrh5NG7y5fDs5
Accept: application/json, text/plain, */*
Cache-Control: no-cache
Authority: example.com
Host: example.com
Connection: close
Response
HTTP/1.1 303 See Other
Date: Tue, 13 Mar 2018 08:55:12 GMT
Content-Type: text/html; charset=UTF-8
Content-Length: 0
Connection: close
Server: nginx
location: S3_SIGNED_URL
Cache-Control: no-cache, private
Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: GET, POST, PUT, DELETE, OPTIONS
Access-Control-Allow-Headers: Content-Type, Accept, Authorization, X-
Requested-With
Access-Control-Max-Age: 28800
Request to S3
GET S3_SIGNED_URL HTTP/1.1
Pragma: no-cache
Origin: https://example.com
Accept-Encoding: gzip, deflate, br
Accept-Language: en-GB,en;q=0.9,en-US;q=0.8,da;q=0.7,de;q=0.6
Authorization: Bearer g6YQjOy3BDu32es8xKdMRNpcQ2Fkrh5NG7y5fDs5
Accept: application/json, text/plain, */*
Cache-Control: no-cache
Authority: example.com
Host: BUCKET_NAME.s3.eu-central-1.amazonaws.com
Connection: close
Response
HTTP/1.1 400 Bad Request
Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: GET
Access-Control-Max-Age: 3000
Vary: Origin, Access-Control-Request-Headers, Access-Control-Request-Method
x-amz-request-id: REQUEST_ID
x-amz-id-2: AMZ_ID
Content-Type: application/xml
Transfer-Encoding: chunked
Date: Tue, 13 Mar 2018 09:06:41 GMT
Connection: close
Server: AmazonS3
<?xml version="1.0" encoding="UTF-8"?>
<Error>
<Code>InvalidArgument</Code>
<Message>Only one auth mechanism allowed; only the X-Amz-Algorithm
query parameter, Signature query string parameter or the Authorization
header should be specified</Message>
<ArgumentName>Authorization</ArgumentName>
<ArgumentValue>Bearer g6YQjOy3BDu32es8xKdMRNpcQ2Fkrh5NG7y5fDs5</ArgumentValue>
<RequestId>REQUEST_ID</RequestId>
<HostId>HOST_ID</HostId>
</Error>
Is there a way to instruct the browser to ignore the Authorization header, or force S3 to ignore the header?
Kind of a kludge, but there is a workaround to this situation by using CloudFront to front S3. More information posted here: ReactJS- remove HTTP header before redirect

Refused to get unsafe header "Location" in chrome and no content in firefox

I am trying to upload an file to ovh object storage (openstack swift), but run into issues.
In Chrome I get:
Refused to get unsafe header "Location"
I tried solving this with by adding 'Access-Control-Expose-Headers': 'Location' to the request headers. But error remains.
In Firefox I get following in the console:
OPTIONS XHR
[HTTP/1.1 200 OK 421ms]
Request Headers:
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Encoding: gzip, deflate, br
Accept-Language: en-US,en;q=0.5
Access-Control-Request-Headers: access-control-expose-headers,tus-resumable,upload-length,upload-metadata,x-auth-token
Access-Control-Request-Method: POST
Connection: keep-alive
Host: storage.gra1.cloud.ovh.net
Origin: http://localhost:8089
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:58.0) Gecko/20100101 Firefox/58.0
Response Headers:
Allow: HEAD, GET, PUT, POST, OPTIONS, DELETE
Content-Length: 0
Date: Thu, 01 Feb 2018 14:55:05 GMT
X-IPLB-Instance: 12318
X-Openstack-Request-Id: txe638462886d66db5ad3c6-005a732a49
X-Trans-Id: txe638462886d66db5ad3c6-005a732a49
access-control-allow-headers: x-auth-token, upload-metadata, upload-length, tus-resumable, access-control-expose-headers
access-control-allow-methods: HEAD, GET, PUT, POST, OPTIONS, DELETE
access-control-allow-origin: *
vary: Access-Control-Request-Headers
POST XHR
[HTTP/1.1 204 No Content 579ms]
Request Headers
Accept: */*
Accept-Encoding: gzip, deflate, br
Accept-Language: en-US,en;q=0.5
Access-Control-Expose-Headers: Location
Connection: keep-alive
Content-Length: 0
Host: storage.gra1.cloud.ovh.net
Origin: http://localhost:8089
Referer: http://localhost:8089/mywebpage
Tus-Resumable: 1.0.0
Upload-Length: 4885581
Upload-Metadata: modelId RmF2b3usrGVz,name MjIyLmpwZz==,type aW1hZ2UvanBlZz==
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:58.0) Gecko/20100101 Firefox/58.0
X-Auth-Token: aSecret000000001
Response Headers
Access-Control-Allow-Origin: *
Access-Control-Expose-Headers: x-trans-id, content-language, X-Container-Read, expires, X-Storage-Policy, last-modified, etag, x-timestamp, pragma, cache-control, content-type, x-openstack-request-id
Content-Length: 0
Content-Type: text/html; charset=UTF-8
Date: Thu, 01 Feb 2018 14:55:05 GMT
X-IPLB-Instance: 12309
X-Openstack-Request-Id: txe638462886d66db5ad3c6-005a732a49
X-Trans-Id: txe638462886d66db5ad3c6-005a732a49
I do not know whether 'No Content' means successful, or something wrong, anyway the file is not send, so probably the last.
My questions:
- How to get rid of the Chrome error message
- How to get the file across.
Access-Control-Expose-Headers should be added to the response by the requested resource's provider (OpenStack Swift), not the client. What you need to do is to configure OpenStack Swift to add this header to its responses.
So how are you going to do it? OpenStack allows you to set/append custom values for Access-Control-Allow-Origin, Access-Control-Max-Age and Access-Control-Expose-Headers for each container. Please see this official document for details.
Example:
Let's create a container and set the custom header values we want to add to the Access-Control-Expose-Headers in the response to the requests made for the objects in this container.
curl -i -X PUT -H "X-Auth-Token: yourtoken" \
-H "X-Container-Meta-Access-Control-Expose-Headers: Location" \
http://192.168.56.3:8080/v1/AUTH_test/cont1
Now for every object you create in this container, you will see Location listed in Access-Control-Expose-Headers and get rid of the error message in Chrome.
You can see the rest of the CORS headers you can configure for each container, in the documentation I linked above.

Strange issue with CORS preflight request fails on IE 11

The problem, is that the the POST query fails on IE11, in all the other browsers it's seems working.
Lets describe the problem step by step:
XHR request from application to REST API.
Preflight OPTIONS request (request parameters are following)
Accept: */*
Origin: https://app.example.com
Access-Control-Request-Method: POST
Access-Control-Request-Headers content-type, accept
:
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/5.0 (Windows NT 6.3; Trident/7.0; rv:11.0) like Gecko
Host: api.example.com
Content-Length: 0
Connection: Keep-Alive
Cache-Control: no-cache
preflight request response parameters are:
X-Powered-By: Sugar
Access-Control-Allow-Origin: https://app.example.com
Vary: Origin
Access-Control-Allow-Credentia true
ls:
Access-Control-Allow-Methods: GET,POST,DELETE,OPTIONS
Access-Control-Allow-Headers: X-Requested-With,X-HTTP-Method-Override,Content-Type,Accept
set-cookie: sugar.sid=s%Pb9OoTTPUkVw%2F2vUPoFMNG
LMXACSkQevo; Path=/; Expires=Thu, 15 Jan 2015 18:27:07 GMT; HttpOnly; Secure
Date: Mon, 12 Jan 2015 18:27:07 GMT
Connection: close
The real HTTP request after preflight request parameters:
Accept: application/json
Content-Type: application/json
Referer: https://app.example.com/
Accept-Language: en-US
Origin: https://app.example.com
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/5.0 (Windows NT 6.3; Trident/7.0; rv:11.0) like Gecko
Host: api.example.com
Content-Length: 9
Connection: Keep-Alive
Cache-Control: no-cache
Cookie: sugar.sid=s%3A-%2FGF1YoFmRfmBsxK4vLBoGjY5NT0QoYvf5s;
Last response parameters:
Content-Type: application/json; charset=utf-8
Content-Length: 72
Vary: Accept-Encoding
Date: Mon, 12 Jan 2015 18:27:07 GMT
Connection: close
Basically the response end with the IE error: Origin: https://app.example.com not found in Access-Control-Allow-Origin header. Does the first request needs also the Access-**-Origin header, which seems to be missing.
Also followed the CORS flow chart for debugging problem, but I could not spot it http://www.html5rocks.com/static/images/cors_server_flowchart.png.
I am using Node.js Express server with the node-cors module + modified options.
I was using Fiddler to debug this issue on my site and got this message:
HTTP/1.1 400 Bad Request
Cache-Control: no-cache
Pragma: no-cache
Content-Type: application/json; charset=utf-8
Expires: -1
Server: Microsoft-IIS/8.5
X-AspNet-Version: 4.0.30319
X-Frame-Options: SAMEORIGIN
X-Content-Type-Options: nosniff
X-XSS-Protection: 1; mode=block
Date: Mon, 12 Sep 2016 19:40:20 GMT
Content-Length: 103
{"Message":"The collection of headers 'accept,if-modified-since,cache-control,pragma' is not allowed."}
CORS the collection of headers accept,if-modified-since,cache-control,pragma
So I just added to my web.api the list of missing headers to CORS.
I hope this helps to someone.

Options Request Successful but still getting Access-Control-Allow-Origin Error

I am making a DELETE request from a Backbone application and am not sure why it fails with the error shown below.
OPTIONS Header
Here is my OPTIONS header which is a 200 Success
Request:
OPTIONS /revenues/674sf6 HTTP/1.1
Host: api2.revparmax.local
Connection: keep-alive
Access-Control-Request-Method: DELETE
Origin: http://localhost:3000
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_6_8) ....
Access-Control-Request-Headers: token, accept, origin, x-requested-with, content-type
Accept: */*
Referer: http://localhost:3000/app/daily/
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8
Response:
HTTP/1.1 200 OK
Date: Mon, 27 May 2013 20:01:32 GMT
Server: Apache/2.2.14 (Unix) DAV/2 mod_ssl/2.2.14 OpenSSL/0.9.8l PHP/5.3.1...
X-Powered-By: PHP/5.3.1
Access-Control-Allow-Origin: http://localhost:3000
Access-Control-Allow-Methods: GET, POST, PUT, DELETE, OPTIONS
Access-Control-Allow-Headers: origin, x-requested-with, content-type, accept, TOKEN
Access-Control-Max-Age: 86400
Content-Length: 2
Keep-Alive: timeout=5, max=100
Connection: Keep-Alive
Content-Type: application/json; charset=utf-8
DELETE header
But then my delete request fails...
Request:
DELETE http://api2.revparmax.local/revenues/674sf6 HTTP/1.1
TOKEN: 00899766786875875674557454
Accept: application/json, text/javascript, */*; q=0.01
Referer: http://localhost:3000/app/daily/
Origin: http://localhost:3000
X-Requested-With: XMLHttpRequest
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_6_8) ....
Content-Type: application/x-www-form-urlencoded; charset=UTF-8
Error
XMLHttpRequest cannot load http://api2.revparmax.local/revenues/674sf6. Origin http://localhost:3000 is not allowed by Access-Control-Allow-Origin.
Note
Oh - I should mention the model still gets deleted from the server but my problem is the Ajax deferred within my backbone app is all thrown off then because of this error.
Also, my request payload when it fails is [object Object] - could that be causing the problem?
Are you running Chrome? If so, then you may have hit the CORS localhost bug. See this SO question.

Categories