I used Charles to record a session and when I check one of the sessions, I found that there is no request body but I can see a response body, I am confused about this as how am I seeing a response without sending a request?
Also, I noticed that I can choose to see the request and response body on my phone's Charles, but on my desktop Charles, I can only see the tab called Content, I tried clicking on the request and response in the under the View tab, nothing happened as well. Does anyone know why?
Thanks!
I am confused about this as how am I seeing a response without sending a request?
A request consists of a few things:
Always: an HTTP method (GET, POST, or similar)
Always: a path (/document/123)
Optional: any number of HTTP headers (my-header: abc)
Optional: a request body
A response consists of:
Always: an HTTP status (404)
Always (in HTTP/1): an HTTP status message (Not Found)
Optional: any number of HTTP headers (my-header: abc)
Optional: a response body
In your case, you are sending a request, it's just that your request only contains a method, URL and headers, but no body. That's totally normal and this is very common for most HTTP requests.
The request and response body are totally independent: it's fine for neither to have a body, or for just one (either one) to have a body, or for both to have a body.
As an example, a GET request to https://google.com/search from a browser will include a method (GET) and a path (/search) and a selection of headers from the browser (such as a user-agent), but won't include any body, and the response will have a status (200) and message (OK), headers about the response data (e.g. content-length: ...) and the body will be the HTML for the google search page.
Related
I'm on a M5Stack atom lite running micropython, making POST requests to a given endpoint with json payload. The following code leads to suspicious behaviour:
if (pin1.value()) == True:
if uart1.any():
try:
req = urequests.request(method='POST', url='https://my-server.com/my-endpoint', json={'requestCode':'yadayada'})
if req.status_code == 200:
rgb.setColorAll(0x00ff00)
rgb.setBrightness(100)
wait_ms(1500)
rgb.setBrightness(0)
else:
rgb.setColorAll(0xff0000)
rgb.setBrightness(100)
wait_ms(1500)
rgb.setBrightness(0)
except:
pass
wait_ms(2)
The first request succeeds and the correct payload is sent to the endpoint. Yet, all subsequent requests fail.
The same holds true for GET requests to https endpoints.
If I change to http, both GET and POST requests work fine, one after another.
Defining the content type in the headers has no effect.
Neither does closing the session right after the request (using headers).
As of request 2, to a https endpoint, I get the exception:
OSError(-17040, 'MBEDTLS_ERR_RSA_PUBLIC_FAILED+MBEDTLS_ERR_MPI_ALLOC_FAILED')
Does anyone see what I'm doing wrong with these https-requests? Thanks in advance for any hints!
I've figured out how to handle a GET request and get all query parameters but couldn't see how to get the JSON body of a POST request. And I went through all the keys of the lighty object but couldn't figure out how where the JSON body is stored. Is there a way to retrieve it?
lighttpd mod_magnet can manipulate the request from the request headers and can short-circuit a response, but the lighttpd hooks from which mod_magnet runs are before the request handler; mod_magnet does not have access to the request body, which may not have been received yet, since the request body is pulled in the request handler.
If you need access to the request body, then your code must run as a request handler. You can run your lua as a CGI script (mod_cgi) or some other backend, e.g. FastCGI (mod_fastcgi), SCGI (mod_scgi), HTTP (mod_proxy), etc.
My API consumes requests only with Header - Content-type:application/json object.
To do the same I use:
#OA\RequestBody(
description= "Provide company search parameter",
required= true,
#OA\JsonContent(
type="object",
#OA\Property(property="company_name", type="string")
)
)
But for some requests I don't need the RequestBody, only hit the resource and get data. How do I do it without RequestBody?
P.S. This request requires a GET method (POST can be used, if that helps) but GET doesn't accept a RequestBody.
This case cannot be described by OAS 3.0, and the restriction on GET requestBodies is to avoid attempting to describe API behaviour which the HTTP spec says is undefined. The restriction on specifying Content-Type as a 'manually' defined header is also to ensure there is no ambiguity as to which mechanism is supposed to set this header.
https://github.com/OAI/OpenAPI-Specification/issues/1628
When a client is sending the Content-Type header, it is used to describe the body of the request (not the response)
To influence the the response type a client can send an Accept header.
For example: Accept: application/json
I am using AngularJS in Safari and in a hybrid iOS application.
I have an HTTP response which is being cached for 10 minutes using the following headers. This response gets cached. We will call this Response A in Step 1.
Cache-Control:public, max-age=600
This gets cached correctly, and after 10 minutes, a new request will be made.
However, I have logic which will cause the client side to ignore the cache due to certain events which would change the response if requested again. When these events occur, I made a new HTTP request with the following request headers to bypass the cache and get a new response. These headers are the only differences between the requests. This is Step 2.
Cache-Control:no-cache, no-store, must-revalidate
Pragma: no-cache
Expires: {Current date time}
This response (Response B) is the same as Response A, except that it has different information in the body. The response headers are identical, other than the Date response header. Making this request successfully bypasses the cache and retrieves the new resource from the server and all is well.
However, this new response does not replace the previous response in the cache. For example, if I navigated to a different page (which does not cause a page reload since my app is a SPA using AngularJS), and then navigated back to the page that makes the same request that was made in Step 1, it gets Response A instead of Response B. I expect Response B to be returned instead.
This is only a problem in Safari. Chrome and IE work correctly in that any future requests will return Response B.
However in Safari, if I do a page reload (⌘ + R), it will ignore the cache completely, and make a brand new request to the same resource. If I hit enter in the Safari URL bar, it does not ignore the cache, but still uses Response A.
How do I get Safari to behave like other browsers and replace cached responses when making new requests which bypass the cache?
To summarize:
Make a request without setting Cache-Control headers in reqeust. Get response with Cache-Control headers called Response A.
Make new request with explicit Cache-Control, Pragma, and Expires request headers which bypass request, get updated Response B.
Navigate away and then back, makes a new request just like in step 1. I expect to get Response B, but get Response A instead. Response B in Step 2 does not replace Response A, even though response headers are mostly identical (except Date header) and the body is different.
I am writing a HTTP Proxy in Delphi 6 using Synapse library.
I know that a regular response has the following syntax:
A Status-line
Zero or more header (General|Response|Entity) fields followed by CRLF
An empty line indicating the end of the header fields
Optionally a message-body
But 100 Continue is not a regular one, is just a inter-response that tells the client to continue and must be followed by a final regular response.
So, should I expect a body in a 100 Continue response?
No, 1xx status responses must not have a body. See http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p1-messaging-26.html#rfc.section.3.3.p.5:
"The presence of a message body in a response depends on both the request method to which it is responding and the response status code (Section 3.1.2). Responses to the HEAD request method (Section 4.3.2 of [Part2]) never include a message body because the associated response header fields (e.g., Transfer-Encoding, Content-Length, etc.), if present, indicate only what their values would have been if the request method had been GET (Section 4.3.1 of [Part2]). 2xx (Successful) responses to a CONNECT request method (Section 4.3.6 of [Part2]) switch to tunnel mode instead of having a message body. All 1xx (Informational), 204 (No Content), and 304 (Not Modified) responses do not include a message body. All other responses do include a message body, although the body might be of zero length."