Send the Old Path Somewhere New

The client side can now resolve any location. This lesson gives it something to resolve: the reading list starts answering its old /v0/books paths with redirects. First, see what an old client gets today. Run the helper’s moved scenario, which sends three requests an old or careless client might send:

python pl_http.py moved

The requests are GET /v0/books/2?x=1, a PUT /v0/books/2 with a JSON book as its body, and GET /books/ with a slash at the end. Each reply starts with HTTP/1.0 404 Not Found. For the first two, nothing exists at /v0 any more; for the third, path_segments gives ["books", ""], and an empty segment is not a book id. All three ask for things the server has, at addresses it no longer answers.

308 for every method

SERVICE_CONTRACT.md says what to send instead. Every request for /v0/books or a path below it, such as /v0/books/2, gets a 308 Permanent Redirect, whatever its method: the move is permanent, and an old client’s PUT or POST must reach the new path unchanged, with its body. The reply carries the new address in location, content-length: 0, and an empty body.

It is tempting to do the work right away instead: the PUT is right there, with a valid book in its body, so why not store it and answer 200? Because then the server has two paths that write, and every rule you add to /books/{id} from now on (Chapter 7 adds who may write at all) has to be added to /v0 as well, or the old path becomes a way around it. A redirect keeps one path that does the work. The client sends the request again to the new path, and only that request changes anything. A redirect answer changes no state at all.

The new branch goes at the top of handle, before the routes you already have, so it answers every method the same way and no method check runs first.

Keep the rest

An old client that asked for /v0/books/7?draft=1 wants book 7, with the same query. The location has to keep everything after /v0: the rest of the path and the query. If it says /books, an old PUT meant for book 7 lands on the collection and gets a 405; if it loses ?draft=1, the request quietly asks for something else.

legacy_location(target) builds that value from the target as it arrived. Take the path with urlsplit(target).path, cut the first three characters, /v0, with a slice, and add ? and the query when there is one. Use the target itself, not the decoded segments from path_segments: the target is already percent-encoded, so it is plain ASCII and fits in a header. A header value must fit in Latin-1 to be written at all, and http.server raises UnicodeEncodeError on a location built from a decoded segment such as ✓, before a single byte of the reply is sent. Because the value starts with /, it is relative: the client resolves it against the URL it asked for, as your resolve_location does, and the server does not have to copy the Host line into every location.

A slash too many

/books/ is a typo for /books, and a common one. The contract answers it with a 301 Moved Permanently to /books. 301 fits a tidy-up meant for reads: a GET for /books/ becomes a GET for /books. A client that sent a POST to /books/ may arrive as a GET after a 301, so its body is lost; a write belongs on the exact path, and the contract asks for 308 only where old clients write. Write the branch for exactly the path /books/, which path_segments turns into ["books", ""]. Nothing else redirects: /books/7/ stays a 404, and so does any /v0 path that is not /v0/books or below it.

redirect(status, location) builds both replies: the status, a location header, content-length set to "0", and the body b"". A redirect has nothing to say in its body, and content-length: 0 tells the client so, framing it like every other reply.

Your task

In reading_server.py:

1. Write redirect(status, location).

2. Write legacy_location(target).

3. At the top of handle, before the /books branches, add two branches: a path whose first two segments are v0 and books gets redirect(308, legacy_location(...)) with the request’s target, and the segments ["books", ""] get redirect(301, "/books"). Leave every other route as it is.

Run the scenario again:

python pl_http.py moved

Each reply now carries a redirect. Read its location line:

server -> client  b'HTTP/1.0 308 Permanent Redirect\r\nServer: ...\r\nDate: ...\r\nlocation: /books/2?x=1\r\ncontent-length: 0\r\n\r\n'
server -> client  b'HTTP/1.0 308 Permanent Redirect\r\nServer: ...\r\nDate: ...\r\nlocation: /books/2\r\ncontent-length: 0\r\n\r\n'
server -> client  b'HTTP/1.0 301 Moved Permanently\r\nServer: ...\r\nDate: ...\r\nlocation: /books\r\ncontent-length: 0\r\n\r\n'

The Server and Date values are left out here; yours name your Python version and the time of the run. The log block lists the three requests with 308, 308 and 301. The PUT changed nothing on the server: only a request that reaches /books/2 can change book 2.

pl_http sends these requests itself and reads exactly what comes back, so it stops at each redirect. So does http.client: asked for /v0/books/2?x=1, it returns the 308 and goes no further. Following is the client’s job, and the next lesson writes the client that does it.

Then press Check my work.