I've built a basic RPC program using FluorineFX (.NET) on the backend for my AMF service. Everything works fine, i.e. I can make calls to the exposed functions.
However, when I looked at Network Monitor in Flash Builder to further examine the network traffic, and then view the Raw Data for the AMF response, it doesn't seem to be compressed/encoded. Also, the response size matches the non-compressed content. My understanding is that these things would be binary. Is there something wrong with my solution or assumptions?
Example: a response (some line breaks added) containing a short array (notice the unencoded body content):
HTTP/1.1 200 OK
Date: Fri, 27 Aug 2010 15:06:49 GMT
Server: Microsoft-IIS/6.0
MicrosoftOfficeWebServer: 5.0_Pub
X-Powered-By: ASP.NET
X-AspNet-Version: 2.0.50727
Cache-Control: private
Content-Type: application/x-amf
Content-Length: 363
Flex Message (flex.messaging.messages.AcknowledgeMessage)
clientId = 29eb2c7f-974b-4bae-8d28-98d4b4dd0547
correlationId = B556E5C3-5476-A92C-2CEC-B4163ABCD1C8
destination = fluorine
messageId = 92675e09-0bc0-498f-b017-7e601b740563
timestamp = 250290640
timeToLive = 0
body = [0, 1, 2, 3, 4, 5, 6, 7, 8, 9]
hdr(DSId) = 6b42848939804b7592eb956797d4eef4
It looks like Network Monitor (available only in Flash Builder Premium) doesn't ever actually show raw AMF data. However, I was mostly interested in response size (i.e. for optimization), which is available. The Response Size (bytes) in the Tree View shows the size of unencoded response, but you can get the encoded size from the Content-Length line in the Raw View.
Related
I've read through the documentation and attempted to setup permanent cloudfront caching. The idea is that once you download an image you shouldn't need to download it again. I'm looking at my network tab and I don't think it is. Can someone tell me if this file has the correct cache settings?
https://d2t4fc8ff77neh.cloudfront.net/cardSrcMedia/1abqkohet_plain_red_heart_graphic_with_a_drop_shadow_0071-0910-0216-0922_SMU.jpg
My headers:
var headers = {
'Content-Length': options.data.length,
'Vary': 'Accept-Encoding',
'Expires': 1000 * 60 * 60 * 24 * 365 * 5,
'x-amz-acl': 'public-read',
'Content-Type': options.type
}
It looks like your image is being cached by CloudFront, but your expires header value isn't valid.
From the HTTP 1.1 spec (https://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html):
The format is an absolute date and time as defined by HTTP-date in
section 3.3.1; it MUST be in RFC 1123 date format
and
HTTP/1.1 clients and caches MUST treat other invalid date formats,
especially including the value "0", as in the past (i.e., "already
expired").
and
To mark a response as "never expires," an origin server sends an
Expires date approximately one year from the time the response is
sent. HTTP/1.1 servers SHOULD NOT send Expires dates more than one
year in the future.
It's probably better to use a Cache-control header as this supersedes the Expires header. Something like this should produce the same effect:
Cache-Control: max-age=31536000
I've read conflicting and somewhat ambiguous replies to the question "How is a multipart HTTP request content length calculated?". Specifically I wonder:
What is the precise content range for which the "Content-length" header is calculated?
Are CRLF ("\r\n") octet sequences counted as one or two octets?
Can someone provide a clear example to answer these questions?
How you calculate Content-Length doesn't depend on the status code or media type of the payload; it's the number of bytes on the wire. So, compose your multipart response, count the bytes (and CRLF counts as two), and use that for Content-Length.
See: http://httpwg.org/specs/rfc7230.html#message.body.length
The following live example should hopefully answer the questions.
Perform multipart request with Google's OAuth 2.0 Playground
Google's OAuth 2.0 Playground web page is an excellent way to perform a multipart HTTP request against the Google Drive cloud. You don't have to understand anything about Google Drive to do this -- I'll do all the work for you. We're only interested in the HTTP request and response. Using the Playground, however, will allow you to experiment with multipart and answer other questions, should the need arise.
Create a test file for uploading
I created a local text file called "test-multipart.txt", saved somewhere on my file system. The file is 34 bytes large and looks like this:
We're testing multipart uploading!
Open Google's OAuth 2.0 Playground
We first open Google's OAuth 2.0 Playground in a browser, using the URL https://developers.google.com/oauthplayground/:
Fill in Step 1
Select the Drive API v2 and the "https://www.googleapis.com/auth/drive", and press "Authorize APIs":
Fill in Step 2
Click the "Exchange authorization code for tokens":
Fill in Step 3
Here we give all relevant multipart request information:
Set the HTTP Method to "POST"
There's no need to add any headers, Google's Playground will add everything needed (e.g., headers, boundary sequence, content length)
Request URI: "https://www.googleapis.com/upload/drive/v2/files?uploadType=multipart"
Enter the request body: this is some meta-data JSON required by Google Drive to perform the multipart upload. I used the following:
{"title": "test-multipart.txt", "parents": [{"id":"0B09i2ZH5SsTHTjNtSS9QYUZqdTA"}], "properties": [{"kind": "drive#property", "key": "cloudwrapper", "value": "true"}]}
At the bottom of the "Request Body" screen, choose the test-multipart.txt file for uploading.
Press the "Send the request" button
The request and response
Google's OAuth 2.0 Playground miraculously inserts all required headers, computes the content length, generates a boundary sequence, inserts the boundary string wherever required, and shows us the server's response:
Analysis
The multipart HTTP request succeeded with a 200 status code, so the request and response are good ones we can depend upon. Google's Playground inserted everything we needed to perform the multipart HTTP upload. You can see the "Content-length" is set to 352. Let's look at each line after the blank line following the headers:
--===============0688100289==\r\n
Content-type: application/json\r\n
\r\n
{"title": "test-multipart.txt", "parents": [{"id":"0B09i2ZH5SsTHTjNtSS9QYUZqdTA"}], "properties": [{"kind": "drive#property", "key": "cloudwrapper", "value": "true"}]}\r\n
--===============0688100289==\r\n
Content-type: text/plain\r\n
\r\n
We're testing multipart uploading!\r\n
--===============0688100289==--
There are nine (9) lines, and I have manually added "\r\n" at the end of each of the first eight (8) lines (for readability reasons). Here are the number of octets (characters) in each line:
29 + '\r\n'
30 + '\r\n'
'\r\n'
167 + '\r\n'
29 + '\r\n'
24 + '\r\n'
'\r\n'
34 + '\r\n' (although '\r\n' is not part of the text file, Google inserts it)
31
The sum of the octets is 344, and considering each '\r\n' as a single one-octet sequence gives us the coveted content length of 344 + 8 = 352.
Summary
To summarize the findings:
The multipart request's "Content-length" is computed from the first byte of the boundary sequence following the header section's blank line, and continues until, and includes, the last hyphen of the final boundary sequence.
The '\r\n' sequences should be counted as one (1) octet, not two, regardless of the operating system you're running on.
If an http message has Content-Length header, then this header indicates exact number of bytes that follow after the HTTP headers. If anything decided to freely count \r\n as one byte then everything would fall apart: keep-alive http connections would stop working, as HTTP stack wouldn't be able to see where the next HTTP message starts and would try to parse random data as if it was an HTTP message.
\n\r are two bytes.
Moshe Rubin's answer is wrong. That implementation is bugged there.
I sent a curl request to upload a file, and used WireShark to specifically harvest the exact actual data sent by my network. A methodology that everybody should agree is more valid than on online application somewhere gave me a number.
--------------------------de798c65c334bc76\r\n
Content-Disposition: form-data; name="file"; filename="requireoptions.txt"\r\n
Content-Type: text/plain\r\n
\r\n
Pillow
pyusb
wxPython
ezdxf
opencv-python-headless
\r\n--------------------------de798c65c334bc76--\r\n
Curl, which everybody will agree likely implemented this correctly:
Content-Length: 250
> len("2d2d2d2d2d2d2d2d2d2d2d2d2d2d2d2d2d2d2d2d2d2d2d2d2d2d646537393863363563333334626337360d0a436f6e74656e742d446973706f736974696f6e3a20666f726d2d646174613b206e616d653d2266696c65223b2066696c656e616d653d22726571756972656f7074696f6e732e747874220d0a436f6e74656e742d547970653a20746578742f706c61696e0d0a0d0a50696c6c6f770d0a70797573620d0a7778507974686f6e0d0a657a6478660d0a6f70656e63762d707974686f6e2d686561646c6573730d0a2d2d2d2d2d2d2d2d2d2d2d2d2d2d2d2d2d2d2d2d2d2d2d2d2d2d646537393863363563333334626337362d2d0d0a")
500
(2x250 = 500, copied the hex stream out of WireShark.)
I took the actual binary there. The '2d' is --- which starts the boundary.
Please note, giving the wrong count to the server treating 0d0a as 1 rather than 2 octets (which is insane they are octets and cannot be compound), actively rejected the request as bad.
Also, this answers the second part of the question. The actual Content Length is everything here. From the first boundary to the last with the epilogue --\r\n, it's all the octets left in the wire.
For WebAPI2 Action results, HTTPResponseMessage is used as one of the return type and Request.CreateResponse is used to return the message.
Request.CreateResponse is handy when we want to return single instance of the model but if we want to return multiple rows from the “model”, there is no overload method for Request.CreateResponse or Request.CreateResponse which supports it(as far as I read). If someone could post the sample, it would be great
Also, I have few other queries.
• Why we have to go for HttpResponseMessage rather than IQueryable or Model return type?
• What is the difference between Request.CreateResponse and Request.CreateResponse , as we are able to return a single instance of the model using both methods. How we can choose one among the two?
You can make the return type of your action method be any serializable data. Content negotiation and formatters will turn the returned value into an HTTP response for you.
From Action Results in Web API 2:
Other Return Types
For all other return types, Web API uses a media formatter to serialize the return value. Web API writes the serialized value into the response body. The response status code is 200 (OK).
public class ProductsController : ApiController
{
public IEnumerable<Product> Get()
{
return GetAllProductsFromDB();
}
}
A disadvantage of this approach is that you cannot directly return an error code, such as 404. However, you can throw an HttpResponseException for error codes. For more information, see Exception Handling in ASP.NET Web API.
Web API uses the Accept header in the request to choose the formatter. For more information, see Content Negotiation.
Example request:
GET http://localhost/api/products HTTP/1.1
User-Agent: Fiddler
Host: localhost:24127
Accept: application/json
Example response:
HTTP/1.1 200 OK
Content-Type: application/json; charset=utf-8
Server: Microsoft-IIS/8.0
Date: Mon, 27 Jan 2014 08:53:35 GMT
Content-Length: 56
[{"Id":1,"Name":"Yo-yo","Category":"Toys","Price":6.95}]
This page on msdn contains definitions of HTTP status codes presumably used in WinHTTP. Is there a way to retrieve HTTP status code from request made in WinHttp?
The only way I've found to get to response text, is to call WinHttpQueryHeaders, which returns HTTP response like this:
HTTP/1.1 404 Not Found
Date: Wed, 28 May 2014 08:20:29 GMT
Content-Length: 0
Server: Microsoft-HTTPAPI/2.0
Do I have to parse this string by myself to get status code, or is there some way already provided by WinHttp to do this?
Use this to read http status code (hRequest - handle of the request).
DWORD dwStatusCode = 0;
DWORD dwSize = sizeof(dwStatusCode);
WinHttpQueryHeaders(hRequest,
WINHTTP_QUERY_STATUS_CODE | WINHTTP_QUERY_FLAG_NUMBER,
WINHTTP_HEADER_NAME_BY_INDEX,
&dwStatusCode, &dwSize, WINHTTP_NO_HEADER_INDEX);
Is there any way we could get directly say the 1000 characters after the first 5000 characters, skipping everything before that after sending in an HTTP request to an HTTPS page using either GET or POST in VB.NET?
The reason why I ask this question is because in one of the webpage I am trying the get through my program, the website is sending response data in chunks with the first chunk containing some javascript garbage that I have no interest in, the only data I care is in the second chunk and
I have no idea how to get the second chunk after receiving the first one since it is within the same HTTP request
It would save some time and Internet traffic if I can skip the first chunk that I do not need.
Is that possible or I am just day dreaming?
Many thanks!
ADDED:
Here is how a typical header of the response I am getting from the webpage I am trying to get:
Date: Mon, 20 Jun 2011 13:21:56 GMT
Set-Cookie: JSESSIONID=1AF1AF9EF936E1CB2FA85B750EDC67C4; Path=****some path******; Secure
Content-Type: text/html; charset=ISO-8859-1
Transfer-Encoding: chunked
Set-Cookie: **********some cookie***************
path=/
Vary: Accept-Encoding, User-Agent
Not sure if that helps, but as you can see, the chunk size is not visible to me, there is no "Trailer" in the header as well.
Fun little problem. Look at RANGE in the following GET request.
GET /file.txt HTTP/1.1
Host: localhost
Range: bytes=5000-6000
Connection: Close
Edit: Found a HTTP example.
Here is an example in PHP. (Sorry I couldn't find any VB.NET examples).