generated from mwc/lab_riddles
36 lines
1.8 KiB
Markdown
36 lines
1.8 KiB
Markdown
# Request and response notes
|
|
|
|
## Checkpoint 1
|
|
Read the request and response shown on lines 1-32 of the lab. Choose
|
|
five lines from the request and/or the response. For each, make an inference
|
|
about the meaning of the line, and some situation in which it might be useful.
|
|
You are welcome to research the meanings of these headers, but it's also
|
|
fine to speculate for now.
|
|
|
|
"Content-Length: 116" is probably the size of the response; not sure what the unit
|
|
here would be...probably bytes since bits probably wouldn't fit all that text? This
|
|
could be useful if the request and response knew how much information was moving
|
|
in each direction maybe as a packet loss check?
|
|
|
|
"X-Content-Type-Options: nosniff" looks interesting; this could be a limit on type
|
|
matching of some kind? Sniffing usually means looking for something so if an option
|
|
is set to not sniff, it's probably forced to some default value. As for what "type",
|
|
that I'm not sure.
|
|
|
|
"Date: Tue, 05 Mar 2024 00:25:26 GMT" is the time when the response was generated. I
|
|
don't know what specific advantage this would provide, but coordination of systems
|
|
or measurements of data transfer speed would be my guesses.
|
|
|
|
"Connection: keep-alive" sounds like it leaves the connection between the to points
|
|
open after the response is passed back. My guess is this speeds up future connections
|
|
because nothing else needs "establishing" from that point on.
|
|
|
|
"Content-Type: application/json" looks like it's reporting the filetype of the response.
|
|
This could be useful in unpacking the response, since if I know what file type I'm
|
|
receiving, I can have it automatically parsed and formatted.
|
|
|
|
## Checkpoint 2
|
|
The goal of this checkpoint is to see what status codes you can get back from
|
|
the riddle server. Paste below several `http` requests and the status codes
|
|
they return.
|