HTTP
Client ↔ Web-Server Communication
The Web Application Landscape
LAMP Stack
Ex. Web Service Stack
Static Pages
Dynamic Pages
Razor Engine
http://www.example.com/somepath/hello.cshtml
<!doctype html>
<head>
<title>C# Loop</title>
</head>
<html>
<body>
@for(var i = 0; i < 10; i++)
{<p>No @i</p>@}
</body>
</html> Software Platforms
- LAMP: Linux, Apache, MySQL, PHP
- MEAN: MongoDB, Express.js, Angular.js, Node.js
- OpenStack: (many, modular)
- WINS: Windows Server, IIS, .NET, SQL Server
- Linux, Nginx, .NET Core, any database (in Docker containers!)
- Choose your own pieces
Web Application Frameworks
- Ruby on Rails (Ruby)
- Django (Python)
- ASP.NET Core 6 (C#)
- Spring MVC (Java)
- Node.js (Javascript)
- Zend (PHP)
- See list
The Conversation
HTTP
Terms
- stateless
- application-level
- extensible
- request/response protocol exchanging messages over a reliable transport connection
- generic interface protocol, independent of the types of resources provided
RFC 7230 (pg 7)
“The Hypertext Transfer Protocol (HTTP) is a stateless application- level request/response protocol that uses extensible semantics and self-descriptive message payloads for flexible interaction with network-based hypertext information systems.”
Message Format
; HTTP/1.1 grammar
HTTP-message = start-line
*( header-field CRLF )
CRLF
[ message-body ]
start-line = request-line / status-line
request-line = method SP request-target SP HTTP-version CRLF
status-line = HTTP-version SP status-code SP reason-phrase CRLF
header-field = field-name ":" OWS field-value OWS
message-body = *OCTET start-line examples
request-line = GET /~morganb/index.html HTTP/1.1 CRLF status-line = HTTP/1.1 304 Not Modified CRLF request-line = GET /~morganb/bad.html HTTP/1.1 CRLF status-line = HTTP/1.1 404 Not Found CRLF
Example
Request Methods RFC 7231
+---------+-------------------------------------------------+-------+ | Method | Description | Sec. | +---------+-------------------------------------------------+-------+ | GET | Transfer a current representation of the target | 4.3.1 | | | resource. | | | HEAD | Same as GET, but only transfer the status line | 4.3.2 | | | and header section. | | | POST | Perform resource-specific processing on the | 4.3.3 | | | request payload. | | | PUT | Replace all current representations of the | 4.3.4 | | | target resource with the request payload. | | | DELETE | Remove all current representations of the | 4.3.5 | | | target resource. | | | CONNECT | Establish a tunnel to the server identified by | 4.3.6 | | | the target resource. | | | OPTIONS | Describe the communication options for the | 4.3.7 | | | target resource. | | | TRACE | Perform a message loop-back test along the path | 4.3.8 | | | to the target resource. | | +---------+-------------------------------------------------+-------+
Status Codes
- 1xx (Informational)
- The request was received, continuing process
- 2xx (Successful)
- The request was successfully received, understood, and accepted
Status Codes (con't)
- 3xx (Redirection)
- Further action needs to be taken in order to complete the request
- 4xx (Client Error)
- The request contains bad syntax or cannot be fulfilled
- 5xx (Server Error)
- The server failed to fulfill an apparently valid request
Status Codes
Common Codes
+------+-------------------------------+--------------------------+ | Code | Reason-Phrase | Defined in... | +------+-------------------------------+--------------------------+ | 200 | OK | Section 6.3.1 | | 304 | Not Modified | Section 4.1 of [RFC7232] | | 400 | Bad Request | Section 6.5.1 | | 403 | Forbidden | Section 6.5.3 | | 404 | Not Found | Section 6.5.4 | | 500 | Internal Server Error | Section 6.6.1 | | 503 | Service Unavailable | Section 6.6.4 | +------+-------------------------------+--------------------------+
Request Header Fields
“A client sends request header fields to provide more information about the request context, make the request conditional based on the target resource state, suggest preferred formats for the response, supply authentication credentials, or modify the expected request processing. These fields act as request modifiers, similar to the parameters on a programming language method invocation.”
Response Header Fields
“The response header fields allow the server to pass additional information about the response beyond what is placed in the status-line. These header fields give information about the server, about further access to the target resource, or about related resources.”
Important Topics
Cacheable Methods
“Request methods can be defined as "cacheable" to indicate that responses to them are allowed to be stored for future reuse ... this specification defines GET, HEAD, and POST as cacheable, although the overwhelming majority of cache implementations only support GET and HEAD”
Safe Methods
GET HEAD OPTIONS TRACE
“Request methods are considered "safe" if their defined semantics are essentially read-only; i.e., the client does not request, and does not expect, any state change on the origin server as a result of applying a safe method to a target resource. Likewise, reasonable use of a safe method is not expected to cause any harm, loss of property, or unusual burden on the origin server.”
Idempotent Methods
PUT DELETE GET HEAD OPTIONS TRACE
“A request method is considered "idempotent" if the intended effect on the server of multiple identical requests with that method is the same as the effect for a single such request.”
Misc
- GET and HEAD requests don't have a body
- GET and HEAD should have no side effects
- Header fields are extensible
- Methods are extensible
- HTTP defaults to TCP port 80
- HTTPS to TCP port 443
How can a website ...
- remember who a visitor is?
- require a password to see a page?
- acquire user data from html forms?
- maintain state information (e.g. values typed into a form)?
- Respond to user input dynamically?
Through HTTP and the browser
- Cookie and Set-Cookie header fields: RFC 6265
- URI Query Strings: RFC 3986, URI
- WWW-Authenticate and Authorization header fields: HTTP Basic Authentication, RFC 7235
- Other methods layered on top of HTTP and HTTPS
- Javascript
Details and specifics will come later
RESTful Web Interface
REST is the architectural style of the Web
“The name 'representational state transfer' is intended to evoke an image of how a well-designed Web application behaves: a network of web pages (a virtual state-machine), where the user progresses through the application by selecting links (state transitions), resulting in the next page (representing the next state of the application) being transferred to the user and rendered for their use.”