Our HTTPRequest/HTTPResponse's .content attribute can currently be either
None, if we have not read the body yet (e.g. in the reponseheaders hook)CONTENT_MISSING=0, if we deliberately deleted the bodyb"", if we read an (empty) body.b"some-content", if we actually read some content.
While the first three values intuitively evaluate to False, I feel the bytes/int/None heterogenity a bit confusing. I'd like to combine the first two cases, so that the type of this attribute can accurately be described as Optional[bytes]. This would fix #692 and make the code IMO easier to understand. We could also first deprecate CONTENT_MISSING gradually by setting it to None, and then remove it later on. @cortesi, would you be okay with this approach?
Our HTTPRequest/HTTPResponse's
.contentattribute can currently be eitherNone, if we have not read the body yet (e.g. in thereponseheadershook)CONTENT_MISSING=0, if we deliberately deleted the bodyb"", if we read an (empty) body.b"some-content", if we actually read some content.While the first three values intuitively evaluate to
False, I feel the bytes/int/None heterogenity a bit confusing. I'd like to combine the first two cases, so that the type of this attribute can accurately be described asOptional[bytes]. This would fix #692 and make the code IMO easier to understand. We could also first deprecateCONTENT_MISSINGgradually by setting it toNone, and then remove it later on. @cortesi, would you be okay with this approach?