same url, http get, postman works and return 200.
copy the url into Chrome, return 500.
The request header differs in postman and chrome, but I am not sure about that and I can't verify this by modifying the request header in chrome.
Postman request header and return 200
Chrome request header but return 500
Url seems to be different.
https://i.stack.imgur.com/eFAhh.png --> has '/1' (url path)
https://i.stack.imgur.com/GzCxk.png --> has '/2' (url path)
Can you check, if same is happening in '/1` in postman
Related
I'm creating a HTTP Web API where some of my resources will be cacheable. A cacheable resource will have two operations, GET & PUT. The GET will return response headers of Cache-Control: public,max-age=3600 & Etag: "2kuSN7rMzfGcB2DKt67EqDWQELA". The PUT will require the If-Match header which will contain the Etag value from a GET of the same resource. My goal is to have the browser cache invalidate a resource when I PUT to that resource. This works fine until I add the If-Match header to the PUT request. When the PUT request contains the If-Match header, subsequent GET requests will fetch from the cache which would be stale data. This is the behavior I've been experiencing with Chrome. Firefox doesn't behave like this, and works as I assume it should. Is this a bug in Chrome or am I misunderstanding some part of the HTTP spec?
Here are some example requests to show behavior:
//correctly fetchs from origin server (returns 200)
GET http://localhost/api/my-number/1
Response Headers
cache-control: public,max-age=3600
etag: "2kuSN7rMzfGcB2DKt67EqDWQELA"
Response Body
7
//correctly fetchs from disk cache (returns 200)
GET http://localhost/api/my-number/1
Response Headers
cache-control: public,max-age=3600
etag: "2kuSN7rMzfGcB2DKt67EqDWQELA"
Response Body
7
//correctly updates origin server (returns 200)
PUT http://localhost/api/my-number/1
Request Headers
if-match: "2kuSN7rMzfGcB2DKt67EqDWQELA"
Request Body
8
//incorrectly still fetches from disk cache (returns 200)
GET http://localhost/api/my-number/1
Response Headers
cache-control: public,max-age=3600
etag: "2kuSN7rMzfGcB2DKt67EqDWQELA"
Response Body
7
This is indeed incorrect behavior. RFC 7234 says:
A cache MUST invalidate the effective Request URI... as well as the URI(s) in the Location and Content-Location
response header fields (if present) when a non-error status code is
received in response to an unsafe request method.
Given that, the bug report you filed looks appropriate to me.
i recorded script with jmeter for 4 transactions.launch, logon, continue, logoff. i am seeing redirecting error for continue transaction and for that i am not seeing any response for that all request. But i am seeing response data in jmeter for all request for continue transaction. i have id token value and that i want to substitute for the next request as post.
Continue transaction
request..response (i am seeing response data with ID_token in jmeter but not in browser)
request (ID_Token as posting here) - Need to get final response for continue transaction.
As per Redirections in HTTP guide:
In HTTP, redirection is triggered by a server sending a special redirect response to a request. Redirect responses have status codes that start with 3, and a Location header holding the URL to redirect to.
As per RFC 2616 the response body is not required for 3xx redirect responses, moreover for 304 Not Modified status it's even forbidden so it's absolutely fine to not to have response body for 3xx status codes as long as you have Location header which points you to the next page.
Just make sure that JMeter sends the same requests and they're treated in the same manner by the server as requests from the real browser by comparing request flow in your browser developer tools and the ones which are sent by JMeter. In case of mismatch play with Redirect automatically and Follow redirects checkboxes in HTTP Request sampler or in HTTP Request Defaults configuration element:
I want to crawl the content of the following page:
http://www.aae3.com/bt/cl/x7btc.php?download=down
When I use Chrome to open this page, I can see an empty file named torrent been downloaded.
If I use devtools in Chrome I can see the request returns 200.
Chrome Devtools Screenshot
And then, I tried to use postman to get this page, no matter how I fill in headers, postman always fail to get any response.
Postman Get Request Test
Why is there such difference? What should I do to get the same behavior with Chrome browser?
Compare the Request Headers, maybe there is a difference another agent Setting which is handled different.
I'm using Postman with the Interceptor extension to perform a POST request.
My request contains an Origin header to be able to avoid CORS errors. The Content-Type is application/x-www-form-urlencoded and I receive json, so I had to add the Accept header with value application/json.
The API I call wants me to add the Referer header as well, so I do that. When I send the request, the Accept header is not in the raw request. When I remove the Referer header, the Accept header shows up in the raw request.
Is this a bug in Postman/Interceptor or am I doing something against 'the rules' of sending http requests?
If I have a Parse.com API with applicationId APPLICATION_ID and REST-API-Key REST_API_KEY, and the classname is Story, then what should the GET request structure look like. I tried the following :
https://api.parse.com/1/story/applicationId=APPLICATION_ID&REST-API-Key=REST_API_KEY
but it didn't work.
#Das According to Parse API
Authentication is done via HTTP headers.
So, your request should be
*GET /1/stories/story HTTP/1.1
Host : api.parse.com
Accept: application/json
X-Parse-Application-Id: APPLICATION_ID
X-Parse-REST-API-Key: REST_API_KEY*
When we need to use headers, the Get request can not be formed within a single URL,
Postman chrome extension would be helpful to construct the requests
or fiddler.
When you are using postman, to fill the header details, take the HTTP Verb as POST and use
X-Http-Method-Override: GET header to make it a GET request.
Hope this helps