HyperText Transfer Protocol

HTTP

HTTP/3

Is a revision of HTTP/2 to use the new protocol QUIC + UDP instead of TCP.

HTTP/2

  • Faster than its predecessors
  • Only one TCP connection
  • Option to server push to client
  • Browser only support HTTP/2 over TLS

HTTP: communication process

HTTP: URL - Unified Resource Locator

HTTP: Requests anatomy 1/4

HTTP: Requests anatomy 2/4

Methods (Verbs)

Verb Action Payload ? Idempotent ?
GET Get a ressource ✔
POST Add a ressource ✔
PUT Modify a ressource ✔ ✔
DELETE Delete a ressource ✔

HTTP: Requests anatomy 3/4

Other Methods

Verb Action Payload ?
PATCH Partial update of a ressource ✔
HEAD GET without the body (only headers)
OPTIONS List allowed Methods for an endpoint

HTTP: Requests anatomy 4/4

Main Request Headers

Content-Encoding, Content-Length, Content-Type...
Format et size of payload

Accept, Accept-Charset, Accept-Encoding, Accept-Languages...
Formats allowed from response

Authorization
Credentials or token

User-Agent
Information on client used (browser)

Cookie
Cookie previously sent by server (Set-Cookie)

HTTP: Response anatomy 1/3

HTTP: Response anatomy 2/3

Status codes (full liste)

Code Description Example
1xx Informational responses 100 Continue
2xx Successful responses 200 OK, 204 No Content
3xx Redirection messages 301 Moved Permanently, 304 Not Modified
4xx Client Error responses 400 Bad Request, 401 Unauthorized, 404 Not Found
5xx Server Error responses 500 Internal Server Error, 503 Service Unavailable

HTTP: Response anatomy 2/3

Main Response Headers

Content-Encoding, Content-Length, Content-Type...
Format et size of payload

Location
Redirect URL

Set-Cookie
Cookie to be stored by client

Transfer-Encoding
Encoding used for payload

Access-Control-Allow-Origin
Allowed origins for CORS

Age / Cache-Control / Expires
Cache control

Security

  • Authorization Header
    • Allows different kind of authentication : Basic, OAuth, Bearer Token, API Key, ...
    • "Authorization: {Type} {Data}"
    • Ex: "Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ=="
      • RFC2045-MIME variant of Base64 encoding of “login:password”
  • Encryption with HTTPS = HTTP over SSL/TLS
    • Asymmetric key derived into a short-term session key for symmetric encryption
    • Used to encrypt the whole HTTP data flow

Practical Work

Call an API with Postman

  • Signup in Postman
  • Take time to play and be familiar with Postman features
    We’ll use it all along the training.
    See how to create collections, create requests, use variables, etc.

This course is graded on the basis of the practical work you will do along the way.
So don't skip the practical work, it's the best way to learn. ;)
Don't hesitate to ask questions if you have any problems.

Gitlab

  • Open source code repository and collaborative software development platform.
  • Powerfull CI/CD capabilities
  • Go and create an account if you don't already have one
  • Play with it: Create a new project, create a Branch, a Merge Request

Assignment

We will use Postman to call Gitlab's REST API.
Using the API, you will:

  • Create a new project with public visibility
  • Create a new branch in this project
  • Create a Merge Request from this branch to the main branch
  • List all the projects you own, and only the ones you own

We will then export the Postman collection and push it to Gitlab, in our new project.

To request Gitlab's API, you will need to use a Personal Access Token.
Use this token in your requests with the Authorization header of type Bearer.

Gitlab REST API Documentation: https://docs.gitlab.com/ee/api/api_resources.html

Push your work to gitlab

  • Install a Git client if you don't already have one (for example Git bash for Windows)
  • Configure your Git client:
    • git config --global user.name "FIRST_NAME LAST_NAME"
    • git config --global user.email "MY_NAME@example.com"
  • Clone your project
    git clone https://gitlab.com/path-to/my-project.git
  • Commit and push it in the previously created branch
    • Export pour Postman Collection in the folder
    • git checkout my-branch
    • git add .
    • git commit -m "My commit message"
    • git push
  • Merge your Merge Request in Gitlab's interface
  • Send me the URL to your project

Client/ Server Stateless (no link between consecutives requests) but not sessionless (with use of cookies, using Headers) HTTP2 is used for around 40% of websites HTTP3 is used for around 26% of websites

- HTTP/2 is more secure as it uses **binary protocol** instead of plaintext. - Multiplexing: HTTP2 uses a single TCP connection to transmit requests and frames, thus eliminating the need for multiple connections. - HTTP/2 **streaming** uses a prioritization tree for more efficient transmission. - HTTP/2 reduced latency by using HPACK compression to shrink the size of headers - HTTP/2 gives an option of **server push** to clients to further speed up the process. ex: curl -v https://www.google.com --http2 -I nc -nlvp 80 / telnet localhost 80 telnet google.com 80 Trying 2a00:1450:4007:819::200e... Connected to google.com. Escape character is '^]'. GET / HTTP/1.1 Host: google.com

Fragment not send to server, only for browser (for example anchors in page)

- These methods allow for Create, Read, Update, Delete operations - An HTTP method is **safe** if it doesn't alter the state of the server - An HTTP method is idempotent if the intended effect on the server of making a single request is the same as the effect of making several identical requests. - All safe methods are also idempotent, but not all idempotent methods are safe - safe/idempotent: Only semantic, no constraint in protocol

Interesting header we don't often manipulate ourselves: Host header positioned by User-Agent, containing target host. Used for example by Kubernetes ingress to route traffic to correct host. In HTTP/2, replaced by pseudo Header ":authority". All pseudo headers begin with ":", they replace HTTP/1 request line and status line

We use symmetric encryption during the session because of lower overhead Asymmetric encryption to exchange session key for security