Paw shows a bunch of great information about a request / response including response time, but I don't see a field for request and/or response size. Is there a way to easily show the size of the response body in Paw?
You usually can see the body size as reported by the server in the Content-Length header, though it is sometimes missing in case of a Transfer-Encoding: chunked response.
There's a dynamic value to get the actual body length of the latest response, as shown below, but it isn't so convenient if you just want to see it yourself (not use it in a subsequent request):
But thanks for the input, we will add a "body size" field in the next version!
Related
If a response to a GET request doesn't have the Content-Length or Transfer-encoding: chunked field, what happens? How does the client know when the message ends?
RFC 7230 section 3.3.3 contains a nice checklist of conditions for finding the message body size. Essentially it says the answer depends on what the status code is. The relevant conditions being #1 and #7.
"1. Any response ... with a 1xx
(Informational), 204 (No Content), or 304 (Not Modified) status
code is always terminated by the first empty line after the
header fields, regardless of the header fields present in the
message, and thus cannot contain a message body."
"7. Otherwise, this is a response message without a declared message
body length, so the message body length is determined by the
number of octets received prior to the server closing the
connection."
Its also worth knowing that the message may continue after the end of the body portion. RFC 7230 section 4.4 defines a Trailers feature where the payload may be followed by a second set of mime headers. If those exist the message ends where they do.
According to the specification
The length of a message body is determined by one of the following (in
order of precedence):
[...]
Otherwise, this is a response message without a declared message body length, so the message body length is determined by the number of octets received prior to the server closing the connection.
The client needs to detect that the connection is closed.
Why are POST params put in the request body, instead of in the URL like GET?
I understand that GET requests are meant to read data, while POST requests are meant to alter data (i.e. if a POST request is sent more than once, dicey things can happen). But why the difference in URL vs body? Putting the text in the body doesn't seem significantly more secure or private.
It's not about security or privacy, but about data.
You can send anything you want in the body, while the URI (specifically the query string) is quite restrictive in content and length.
The HTTP request has two parts: The header and the body
The header contains all information which describes the request and the requested object (path, request parameters, options, etc) and the requested operation (GET, POST, PUT, DELETE, etc).
The body contains all data which are sent by the client to process. This data could be some kind of binary data (an image for example), or some kind of form data (POST data).
This is the HTTP request specification: http://www.w3.org/Protocols/rfc2616/rfc2616-sec5.html
Here are the definitions of the HTTP request methods:
http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html
I'm trying to retrieve my contacts using curl. I've succeeded in getting my authToken, and now am getting an error stating that I need to set the content-length in the header, but when I set the content length to 0 I get a "bad request" error.
Does anyone know what the content length is? Is it the length of the Auth key? or the length of the entire header field that contains it? I'm just poking around in the dark, and the google api doesn't seem to explain what it's looking for.
According to the HTTP standard, content-length must be greater then or equal to zero. This header can cause a "bad request" problem if:
A 'transfer-encoding' header is included in the request with certain values or
If the content-length is less than the actual length
A content-length less than zero is sent
Content length should be the size of the message body (not including headers). This would include POST data (presumably how your authToken is sent) sent with the request.
The length sent shouldn't need to be exact (though you should try!). Most browsers don't care about the length (as long as it is greater than the actual content length). If it is less than the actual content length, most browsers choke, but not the other way around. I'm assuming Google's servers will act similarly.
So, the solution appears to be that
a) the second request is a GET not a POST
and
b) the username I was passing in requires a fully qualified email (boo#gmail.com, not just boo)
I'm having trouble finding a definite specification of this in the standard. I have an HTTP client that's not including a Content-Length: 0 header when doing a PUT request where I don't specify a body, and a server that gets confused by such requests, and I'm wondering which program I should be blaming.
HTTP requests have a body if they have a Content-Length or Transfer-Encoding header (RFC 2616 4.3). If the request has neither, it has no body, and your server should treat it as such.
That said it is unusual for a PUT request to have no body, and so if I were designing a client that really wanted to send an empty body, I'd pass Content-Length: 0. Indeed, depending on one's reading of the POST and PUT method definitions (RFC 2616 9.5, 9.6) one might argue that the body is implied to be required - but a reasonable way to handle no body would be to assume a zero-length body.
Not answering the question, but asserting how jaxrs allows me to frequent use of bodyless PUTs:
Example of bodyless put:
Give user an additional permission.
PUT /admin/users/{username}/permission/{permission}
A body is not required by the IETF standard, though the content-length should be 0 if there's no body. Use the method that's appropriate for what you're doing. If you were to put it into code, given
int x;
int f(){ return x; }
and a remote variable called r.
A post is equivalent to
r=f();
A put is equivalent to
r=x;
and a get is equivalent to
x=r;
What is being PUT (in the verb sense) onto the server if there's no content? The spec refers to the content as "the enclosed entity", but a request with no content would have no enclosed entity, and therefore nothing to put on the server.
Unless, of course, you wanted to PUT nothing onto the server, in which case you'd probably want a DELETE instead.
The content length field is required as per the following section in the HTTP/1.1 standard http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.13
I have been trying to stream audio from a particular point by using the Range header values but I always get the song right from the beginning. I am doing this through a program so am not sure whether the problem lies in my code or on the server.
How can I find out whether the server supports the Range header param?
Thanks.
The way the HTTP spec defines it, if the server knows how to support the Range header, it will. That in turn, requires it to return a 206 Partial Content response code with a Content-Range header, when it returns content to you. Otherwise, it will simply ignore the Range header in your request, and return a 200 response code.
This might seem silly, but are you sure you're crafting a valid HTTP request header? All too commonly, I forget to specify HTTP/1.1 in the request, or forget to specify the Range specifier, such as "bytes".
Oh, and if all you want to do is check, then just send a HEAD request instead of a GET request. Same headers, same everything, just "HEAD" instead of "GET". If you receive a 206 response, you'll know Range is supported, and otherwise you'll get a 200 response.
This is for others searching how to do this. You can use curl:
curl -I http://exampleserver.com/example_video.mp4
In the header you should see
Accept-Ranges: bytes
You can go further and test retrieving a range
curl --header "Range: bytes=100-107" -I http://exampleserver.com/example_vide0.mp4
and in the headers you should see
HTTP/1.1 206 Partial Content
and
Content-Range: bytes 100-107/10000000
Content-Length: 8
[instead of 10000000 you'll see the length of the file]
Although I am a bit late in answering this question, I think my answer will help future visitors. Here is a python method that detects whether a server supports range queries or not.
def accepts_byte_ranges(self, effective_url):
"""Test if the server supports multi-part file download. Method expects effective (absolute) url."""
import pycurl
import cStringIO
import re
c = pycurl.Curl()
header = cStringIO.StringIO()
# Get http header
c.setopt(c.URL, effective_url)
c.setopt(c.NOBODY, 1)
c.setopt(c.HEADERFUNCTION, header.write)
c.perform()
c.close()
header_text = header.getvalue()
header.close()
verbose_print(header_text)
# Check if server accepts byte-ranges
match = re.search('Accept-Ranges:\s+bytes', header_text)
if match:
return True
else:
# If server explicitly specifies "Accept-Ranges: none" in the header, we do not attempt partial download.
match = re.search('Accept-Ranges:\s+none', header_text)
if match:
return False
else:
c = pycurl.Curl()
# There is still hope, try a simple byte range query
c.setopt(c.RANGE, '0-0') # First byte
c.setopt(c.URL, effective_url)
c.setopt(c.NOBODY, 1)
c.perform()
http_code = c.getinfo(c.HTTP_CODE)
c.close()
if http_code == 206: # Http status code 206 means byte-ranges are accepted
return True
else:
return False
One way is just to try, and check the response. In your case, it appears the server doesn't support ranges.
Alternatively, do a GET or HEAD on the URI, and check for the Accept-Ranges response header.
You can use GET method with 0-0 Range request header, and check whether the response code is 206 or not, which will respond with
the first and last bytes of the response body
You also can use HEAD method do the same thing as the first session which will get the same response header and code without response body
Furthermore, you can check Accept-Ranges on the response header to judge whether it can support range, but please notice if the value is none on Accept-Ranges field, it means it can't support range, and if the response header doesn't have Accept-Ranges field you also can't finger out it can't support range from it.
There is another thing you have to know if you are using 0- Range on the request header with GET method to check the response code, the response body message will be cached automatically on the TCP receive window until the cache is full.