Chapter 9 ■ http Clients165Note that this mechanism, as implemented by Requests or other modern libraries, is not the full-fledged
protocol! The username and password specified previously have not been tied to any specific realm. There is no
401 response involved that could even provide a realm because the username and password are being supplied
unilaterally with the request without checking first whether the server even wants them. The auth keyword argument,
or the equivalent Session setting, is merely a way to set the Authorization header without having to do any base-64
encoding yourself.
Modern developers prefer this simplicity to the full realm-based protocol. Typically, their only goal is for GET
or POST requests to a programmer-targeted API to be authenticated independently with the identity of the user or
application making the request. A unilateral Authorization header is perfect for this. It also has another advantage:
time and bandwidth is not wasted getting an initial 401 when the client already has good reason to believe that the
password will be required.
If you wind up talking to a true legacy system that needs you to use different passwords for different realms on the
same server, then Requests gives you no help. It will be up to you to use the right password with the right URLs. This is a
rare area in which urllib is capable of doing the right thing and Requests is not! But I have never heard a single complaint
about this shortcoming in Requests, which is an indication of how rare true Basic Auth negotiation has become.
Cookies
HTTP-mediated authentication is rare today. It was, in the end, a losing proposition for HTTP resources that were
designed to be visited by people using a web browser.
What was the problem with HTTP authentication and users? Web site designers typically want to perform
their own authentication in their own way. They want a custom and friendly login page that follows their own user
interaction guidelines. The sad little pop-up window that web browsers offer when challenged for in-protocol HTTP
authentication are intrusive. They are not terribly informative, even at the best of times. They take the user completely
out of the experience of a site. Also, any failure to type in the right username and password can result in the pop-up
appearing over and over again, without the user knowing what is going wrong or how they can correct it.
And so cookies were invented.
A cookie, from the point of view of the client, is an opaque key-value pair. It can be delivered in any successful
response that the client receives from the server.
GET /login HTTP/1.1
...
HTTP/1.1 200 OK
Set-Cookie: session-id=d41d8cd98f00b204e9800998ecf8427e; Path=/
...
When making all further requests to that particular server, the client includes that name and value in a
Cookie header.
GET /login HTTP/1.1
Cookie: session-id=d41d8cd98f00b204e9800998ecf8427e
...
This made site-generated login pages possible. When a login form is submitted with invalid credentials, the
server can present it again with as many helpful hints or support links as it pleases, all styled exactly like the rest of the
site. Once the form is submitted correctly, it can grant the client a cookie that is specially crafted to convince the site of
the user’s identity during all subsequent requests.