Trying to get chunked content with Google AppScript UrlFetchApp:
UrlFetchApp.fetch(url, {muteHttpExceptions:true});
Unfortunately, it does not handle it well and stops after first chunk or somewhere between.
Here are the HTTP response headers:
HTTP/1.1 200 OK
access-control-allow-credentials: true
access-control-allow-origin: *
access-control-expose-headers:
cache-control: max-age=0, private, must-revalidate
content-type: application/json; charset=utf-8
date: Fri, 26 Oct 2018 11:15:24 GMT
x-request-id: 2lgi8mvh6onm5jrvf8000tl1
transfer-encoding: chunked
Connection: keep-alive
Does UrlFetchApp even support chunked responses? If not, is there any alternative?
Related
I'm migrating a Shopify app from EASDK to App-Bridge. I have replaced the old API calls with the new ones, but the app is not loaded in the Shopify admin panel. I get an error in a JS console
Refused to display in a frame because it set 'X-Frame-Options' to 'SAMEORIGIN
the wget command shows this:
HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
Transfer-Encoding: chunked
Connection: keep-alive
Status: 200 OK
Cache-Control: max-age=0, private, must-revalidate
Vary: Accept
Referrer-Policy: strict-origin-when-cross-origin
X-Permitted-Cross-Domain-Policies: none
X-XSS-Protection: 1; mode=block
X-Request-Id: 91a511cf-d434-43af-96b8-318356bbbb9a
Link: </assets/application-63f0e6a6cb6a5ecd85ba82b031064ed920a1015deae96cc86bf3de0f7f1c5eaf.css>; rel=preload; as=style; nopush,</assets/application-3111a09ab2c1b26ba99f1c96028fdc2f1677b792d7407284f5182655a8a722d7.js>; rel=preload; as=script; nopush
X-Download-Options: noopen
ETag: W/"e8fc9609e43ff20b0c13c3000ecf4f26"
X-Frame-Options: SAMEORIGIN
X-Runtime: 0.004762
X-Content-Type-Options: nosniff
Date: Tue, 29 Mar 2022 09:59:33 GMT
Set-Cookie: _product_image_slider_session=rpnUJ5yt9PH0EEIHRo4p0RWSKraymAdpsqLh%2BPHGuNx6VU25KhA%2BBxvY4nJDHgSkxQBbacT7SyG%2BGna9bpYxCS7sWGUliu3mlPKM7Df13xbfA%2F8B%2BZ%2FKhC0E00ulV990mmeCkaV0GrrsokmodJZRg76R1ArJTNUoi4PQ54YnQCtiScogv8F38KLC2dJI%2B8eaI6j%2F0U2X6IN87nzm3RhP6dcQsNb1%2BjqvhnxScQuGW37nr84dMzpM4lJscWYElvC6cKqo3Wa897bLnkjFy46m%2BQvBo5KRXyIzqXM%2FJxyqy%2FeDUAv5qg%3D%3D--1h%2B8JkCqosbY%2FtH%2B--5mkT1eQTPoFBpn8nXLkFUQ%3D%3D; path=/; HttpOnly; SameSite=Lax
X-Powered-By: Phusion Passenger(R) 6.0.12
Server: nginx/1.18.0 + Phusion Passenger(R) 6.0.12
Strict-Transport-Security: max-age=31536000
X-Frame-Options: https://grid-kit.myshopify.com
I had a look through the nginx config and I cannot find anywhere this X-Frame-Options' to 'SAMEORIGIN header. I even added new header X-Frame-Options (see a screenshot) with the correct website, but this won't help. I just get a message of Multiple 'X-Frame-Options' headers with conflicting values ('SAMEORIGIN, https://grid-kit.myshopify.com') encountered when loading 'https://app.gridkit.net/?
Where to find the solution?
I have a simple post request with axios:
axios.post('my endpoint', values).then(res => console.log(res.headers));
axios is listing those values as headers:
cache-control: "max-age=0, private, must-revalidate"
content-length: "13757"
content-type: "application/xml; charset=utf-8"
but when I check the network tab in chrome, I can see those values under response headers:
access-control-allow-origin: http://localhost:8080
access-control-expose-headers: Total,Total-Pages
cache-control: max-age=0, private, must-revalidate
content-length: 13757
content-type: application/xml; charset=utf-8
date: Thu, 02 Sep 2021 19:37:42 GMT
x-envoy-upstream-service-time: 385
x-request-id: FqEYfGCtbcHGzzwASr4C
I need to access the x-request-id header, but there is no way to get this with axios or fetch.
I saw some messages about the header being blocked by cors, but I have X-Request-Id in my access-control-allow-headers
Someone has any idea how to get this header with axios?
I think you have to specify this on the server so that axios has access to the specific headers you require.
https://stackoverflow.com/a/37931084/8818020
I'm writing a function in my node server that detects whether a particular URL can be rendered inside an i-frame by checking the x-frame-options field in the header.
While this works correctly, for some sites I am receiving a header without this field when accessed through the http module. However the header for these sites correctly includes this option when opened in the browser.
For example: when accessing artstation.com:
In Node.js the Response headers are:
{"date":"Fri, 17 Jan 2020 03:37:06 GMT",
"connection":"close","cache-control":"private,
max-age=0, no-store, no-cache, must-revalidate,
post-check=0, pre-check=0","expires":"Thu, 01 Jan 1970 00:00:01 GMT",
"location":"https://www.artstation.com/",
"x-content-type-options":"nosniff",
"server":"cloudflare",
"cf-ray":"556549e5fbeaefd8-EWR"}
In Chrome browser the response headers are:
cache-control: max-age=0, private, must-revalidate
cf-cache-status: DYNAMIC
cf-ray: 5565511b5d3fe6d0-EWR
content-encoding: gzip
content-type: text/html; charset=utf-8
date: Fri, 17 Jan 2020 03:42:01 GMT
expect-ct: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct"
server: cloudflare
set-cookie: _ArtStation_session=TEFNMnlrR0UrK1A0UTgzM2FqOGJhMXZkU2dhYitxVW83ajJhMXo0SzJ4T0tENGhwYVppVTZpL0lOSHZ1M0pmRERRaUZ5Z0FTMWRuWTRsTm95VHQwUlhlcEdXN1JCSGtsL0pPdHNtSFF4R3ZScjhUOHFDOWkrSEg3RjNoemZ5aFVWMGJweXFwQU56Q3dOV25icXNNNGtjK3RwbDB4Tml0cjZWSHRWZ1dMK0FSajl2OHZoazFrckVaSTcyRkxFRHAzbHQrbTlpUnZudmRoVXNKYkF5TmlyUT09LS1rVkhhWG5OZ3ZOK0hUckdhY0pRbDJ3PT0%3D--083e61c9e5af420688bc4d309212aafb2de70ebb; domain=.artstation.com; path=/; expires=Fri, 17 Jan 2020 05:12:01 -0000; secure; HttpOnly
status: 200
status: 200 OK
strict-transport-security: max-age=0
x-content-type-options: nosniff
x-frame-options: SAMEORIGIN
x-powered-by: Phusion Passenger Enterprise
x-request-id: 1e36371b-eb7c-419e-97ae-6c9ac901c240
x-runtime: 0.040934
x-xss-protection: 1; mode=block
As you can see the x-frame-options: SAMEORIGIN is present in the response headers in Chrome but not in Node.
Why are the response headers different?
Also, please note that this behaviour does not apply to all sites. When accessing google.com, the headers match in the browser and node.
I have a problem with Chrome - in the network tab it only displays an empty Access-Control-Exposed-Headers header.
In postman the header's value is visible:
When trying to access the ETag header through the getResponseHeader('ETag') method of the XMLHttpRequest I'm getting a Refused to get unsafe header "etag" error. I already ran out of ideas how to fix this. Does anybody know what could be wrong?
EDIT: Apparently that behaviour is caused by the Origin header - when it is present in the request, the Access-Control-Expose-Headers in the response is empty. Unfortunately, I don't have access to the backend code, so I can't provide an example. All response headers:
HTTP/1.1 200 OK
Server: openresty/1.9.7.5
Date: Sun, 03 Sep 2017 13:02:55 GMT
Content-Type: application/json; charset=utf-8
Transfer-Encoding: chunked
Connection: keep-alive
X-Frame-Options: SAMEORIGIN
X-XSS-Protection: 1; mode=block
X-Content-Type-Options: nosniff
Access-Control-Allow-Origin: http://localhost:3000
Access-Control-Expose-Headers:
Access-Control-Allow-Methods: GET, POST, PUT, DELETE, OPTIONS
Access-Control-Allow-Headers: *,x-requested-with,Content-Type,If-Modified-Since,If-None-Match,latest_time
Access-Control-Max-Age: 1728000
ETag: "eef3e52bc505031d93da42098f32cc60"
Cache-Control: max-age=0, private, must-revalidate
X-Request-Id: eb5c7353-0b4b-43c8-b2ff-4763d56d9ec9
X-Runtime: 0.015680
Access-Control-Allow-Credentials: true
Vary: Origin
The FourSquare API documentation states that it supports CORS. However calling to the /users/ endpoints clearly states that only GET requests are supported:
curl -X OPTIONS -i "https://api.foursquare.com/v2/users/self/checkins?oauth_token=CLIENT_OAUTH_TOKEN"
HTTP/1.1 405 Method Not Allowed
Access-Control-Allow-Origin: *
Cache-Control: no-cache, private, no-store
Content-Type: application/json; charset=utf-8
Date: Wed, 13 Feb 2013 04:31:54 GMT
Expires: Wed, 13 Feb 2013 04:31:54 GMT
Pragma: no-cache
Server: nginx/1.2.1
Tracer-Time: 17
Content-Length: 104
Connection: keep-alive
{"meta":{"code":405,"errorType":"other","errorDetail":"This endpoint only supports GET."},"response":{}}
Is this just particular to these API endpoints or has something changed?
I haven't looked into all the methods in the FourSquare API, but my guess is that FourSquare doesn't need to support preflight requests because all their API requests are simple. The docs here suggest that the API only supports GET and POST. If those requests don't have any custom headers, they will never need a preflight request.