Conversation
src/werkzeug/wrappers/request.py
Outdated
| @property | ||
| def is_secure(self) -> bool: | ||
| "`True` if the request is secure." | ||
| return self.scheme in {"https", "wss"} |
There was a problem hiding this comment.
This is a change from the previous code, but I think it makes sense.
pgjones
force-pushed
the
wrappers
branch
2 times, most recently
from
a06c412 to
2bf997c
Compare
|
Why were only some of the WSGI values extracted? https://asgi.readthedocs.io/en/latest/specs/www.html#wsgi-compatibility It seems like you'd also want at least |
|
I'm not sure I've updated with REMOTE_ADDR usage, thanks. |
|
The link I posted suggests Could you give a brief outline on the issues with |
|
Updated the script_info usage, to use See also django/asgiref#229 for a potential issue with ASGI and root_path. |
This might be clearer if you consider the names as `BaseRequest` and `WSGIRequest` (although these names aren't possible for compatibility reasons). The `SansIORequest` contains all the information that is not WSGI or IO dependent thereby allowing it to be used in ASGI projects, notably Quart. This has a very slight performance impact as the path, scheme, headers, and method are no longer lazily loaded. However, this impact is likely just a dictionary lookup. The changes in other files are minor typing improvements related to the typing changed in the request wrappers.
This might be clearer if you consider the names as `BaseResponse` and `WSGIResponse` (although these names aren't possible for compatibility reasons). The `SansIOResponse` contains all the information that is not WSGI or IO dependent thereby allowing it to be used in ASGI projects, notably Quart.
This makes the naming a little easier (called request and response), and allows the sansio module to be considered private/development. The latter is desired as it isn't clear (yet) how to specify the IO interface - in an abstract manner so that both sync and async implementations exist. This also allows further sansio, rather than WSGI based code, to be added in a clear location - clear to future authors that the code must not be WSGI or ASGI or IO specific.
|
Thanks! |
2 participants
This might be clearer if you consider the names as
BaseRequest/BaseResponseandWSGIRequest/WSGIResponse(although these names aren't possible for compatibility reasons). TheSansIORequest/SansIOResponsecontains all the information that is not WSGI or IO dependent thereby allowing it to be used in ASGI projects, notably Quart.Does this need specific docs? (At this stage?)
Checklist:
CHANGES.rstsummarizing the change and linking to the issue... versionchanged::entries in any relevant code docs.pre-commithooks and fix any issues.pytestandtox, no tests failed.