The two types of HTTP information are header and content.
The content segment is introduced by the header. In the header, the client or the server (their headers are similar but not identical) communicates a lot about what it wants, who it is, and what it is sending. Among its interesting functions are the following:
404: File not found 200: OK
From: firstname.lastname@example.org Host: 22.214.171.124:8080
Cache-control: no-store Connection: close
Server: NCSA/1.3 User-Agent: Mozilla /1.1 (Macintosh; I 68K)
Accept: image/gif Accept: */*
Set-Cookie: user=JesseJ Cookie: user=JesseJ
Content-type: text/xml Content-length: 1024
H EADERS WITHIN H EADERS
HTTP is most commonly used to transfer HTML. It is easy to confuse the HTTP header with the HTML header. The latter is, naturally, part of the HTML document, which is the content of the HTTP transfer. HTML headers are HTTP content.
This point can continue recursively. A page represented by HMTL will often have a human-readable header ”letterhead, headline, banner. This "header" is part of the HTML body.
XML documents are similarly divided into prologue (header) and body. Both are in the content portion of the HTTP exchange.
Upstream HTTP Transfer
There are two main methods with which an HTTP client can send information upstream to the server. They are GET and POST. (There are other variants, like PUT, a protocol that implements some FTP-like functionality. We exclude these from our discussion because they are not supported by Flash.)
A GET request requires no content body. Information to the host is embedded in the URL. A question mark separates the document identifier portion of the URL from the upstream datagram. Any observant web surfer has seen this format often: It is a popular method of querying a server-based application. It has the advantage that a single URL string not only identifies the web resource but also packages a lot of context and query information. This makes it easy for a simple hyperlink on your web site to contact a web-based map server and retrieve a map to your office.
The disadvantages of GET include the fact that it usually exposes data communications to the user and that it is limited in the length of data string permissible. The former is not much of a problem in Flash, but the latter is a restriction imposed by the server to which Flash must conform.
It is frustrating to report that there is no precise limit on the length of the data string. Different software imposes different restrictions, and the restrictions go beyond buffer size limits. Strings are often concatenated by other processes in ways that are hard to anticipate. Some software breaks lines and breaks URLs (the interaction of e-mail and GET strings is a special nightmare). However, for most straight applications, such as a direct request from Flash to a server, 150 characters are often quoted as a safe rule of thumb.
An alternative form of upstream data communications is POST. In this protocol the HTTP header alerts the server that it is followed by a content packet.
Data is transmitted in a format called application/x-www-form-urlencoded , which has the following features:
When using loadVariables , Flash will urlencode the variables automatically. If you need to manually encode a string, use the Flash method escape() ; to de-urlencode, use unescape () .