You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: course-definition.yml
+50-31Lines changed: 50 additions & 31 deletions
Original file line number
Diff line number
Diff line change
@@ -638,68 +638,87 @@ stages:
638
638
639
639
- slug: "df4"
640
640
primary_extension_slug: "http-compression"
641
-
name: "Content-Encoding header"
641
+
name: "Compression headers"
642
642
difficulty: easy
643
643
description_md: |
644
-
Welcome to the HTTP Compression Extension! In this extension, you'll add [Compression](https://en.wikipedia.org/wiki/HTTP_compression) support to your HTTP Server implementation.
644
+
Welcome to the HTTP Compression extension! In this extension, you'll add support for [compression](https://en.wikipedia.org/wiki/HTTP_compression) to your HTTP server.
645
645
646
-
In this stage, you'll add support for the Content-Encoding header based on what the client sends.
646
+
In this stage, you'll add support for the `Accept-Encoding` and `Content-Encoding` headers.
647
647
648
-
### Tests
648
+
### `Accept-Encoding` and `Content-Encoding`
649
649
650
-
The tester will execute your program like this:
650
+
An HTTP client uses the `Accept-Encoding` header to specify the compression schemes it supports. In the following example, the client specifies that it supports the `gzip` compression scheme:
651
+
```
652
+
> GET /echo/foo HTTP/1.1
653
+
> Host: localhost:4221
654
+
> User-Agent: curl/7.81.0
655
+
> Accept: */*
656
+
> Accept-Encoding: gzip // Client specifies it supports the gzip compression scheme.
657
+
```
651
658
652
-
```bash
653
-
./your_server.sh
659
+
The server then chooses one of the compression schemes listed in `Accept-Encoding` and compresses the response body with it.
660
+
661
+
Then, the server sends a response with the compressed body and a `Content-Encoding` header. `Content-Encoding` specifies the compression scheme that was used.
662
+
663
+
In the following example, the response body is compressed with `gzip`:
664
+
```
665
+
< HTTP/1.1 200 OK
666
+
< Content-Encoding: gzip // Server specifies that the response body is compressed with gzip.
667
+
< Content-Type: text/plain // Original media type of the body.
668
+
< Content-Length: 23 // Size of the compressed body.
669
+
< ... // Compressed body.
654
670
```
655
671
656
-
It'll then send an HTTP `GET` request to the `/echo/<a-random-string>` endpoint. In the request, it'll include an Accept-Encoding header like: `Accept-Encoding: gzip`.
657
-
As an example, here's a request you might receive:
672
+
If the server doesn't support any of the compression schemes specified by the client, then it will not compress the response body. Instead, it will send a standard response and omit the `Content-Encoding` header.
658
673
674
+
For this extension, assume that your server only supports the `gzip` compression scheme.
675
+
676
+
For this stage, you don't need to compress the body. You'll implement compression in a later stage.
677
+
678
+
### Tests
679
+
680
+
The tester will execute your program like this:
659
681
```
660
-
GET /echo/foo HTTP/1.1
661
-
Host: localhost:4221
662
-
User-Agent: curl/7.64.1
663
-
Accept-Encoding: gzip
682
+
$ ./your_server.sh
664
683
```
665
684
666
-
Your server must respond with a `200 OK` response. The response should have a `Content-Encoding: gzip` header present. The response body will not be tested in this stage. (We will tackle the actual compression in a later stage)
667
-
Here's the response you're expected to send back:
685
+
The tester will then send two `GET` requests to the `/echo/{str}` endpoint on your server.
686
+
687
+
#### First request
688
+
689
+
First, the tester will send a request with this header: `Accept-Encoding: gzip`.
Your server's response must contain this header: `Content-Encoding: gzip`.
669
695
```
670
696
HTTP/1.1 200 OK
671
-
Content-Encoding: gzip
672
697
Content-Type: text/plain
673
-
Content-Length: 3
698
+
Content-Encoding: gzip
674
699
675
-
foo
700
+
... // Body omitted.
676
701
```
677
702
678
-
It'll then send another HTTP `GET` request to the `/echo/<a-random-string>` endpoint. In the request, it'll include an Accept-Encoding header like: `Accept-Encoding: invalid-encoding`.
679
-
But this time the Accept-Encoding header will be set to an invalid value (i.e. an encoding that your server doesn't support).
680
-
As an example, here's a request you might receive:
703
+
#### Second request
681
704
705
+
Next, the tester will send a request with this header: `Accept-Encoding: invalid-encoding`.
Your server must respond with a `200 OK` response. The response should NOT have a `Content-Encoding` header present. The response body will not be tested in this stage.
690
-
Here's the response you're expected to send back:
691
-
710
+
Your server's response must not contain a `Content-Encoding` header:
692
711
```
693
712
HTTP/1.1 200 OK
694
713
Content-Type: text/plain
695
-
Content-Length: 3
696
714
697
-
bar
715
+
... // Body omitted.
698
716
```
699
717
700
718
### Notes
701
719
702
-
1. Header names are case-insensitive, i.e. `accept-encoding: gzip` and `Accept-Encoding: gzip` are equivalent. We won't test this explicitly in this challenge, but it's a good practice to lowercase your header names before comparison.
720
+
- You'll add support for `Accept-Encoding` headers with multiple compression schemes in a later stage.
721
+
- There's another method for HTTP compression that uses the `TE` and `Transfer-Encoding` headers. We won't cover that method in this extension.
703
722
marketing_md: |
704
723
In this stage, you'll add support for reading the `Accept-Encoding` header sent by clients, and respond with `Content-Encoding` header in your response.
0 commit comments