-
-
Notifications
You must be signed in to change notification settings - Fork 2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Expect: 100-continue #267
Comments
I don't understand your question clean, sorry. |
No, if I make a response: return Response(status=100) aiohttp just closes connection. Curl output:
Working code is: request.transport.write(b"HTTP/1.1 100 Continue\r\n") It is possible to handle authomatically in Request? |
@tumb1er what is your use case for 100-continue ? |
If it's like SIP protocol, it's to notify the client that the request is received, response will arrive. |
@fafhrd91 it's only an observation of how curl works with post requests.
|
that is wrong reason for feature. by implementing this response you close ways to use this feature properly. i prefer no to have it rather have wrong implementation. |
So every aiohttp user MUST now implement Expect: header processing by himself, to make aiohttp library HTTP/1.1 compatible? I think, with def handle(request):
# First, check all request properties without reading a payload
if check_headers_and_path(request) != "ok":
# if not OK, send 417, or 403 or whatever else... (server MUST continue reading
# or response with final status code)
return Response(status=417)
# if ok, request.post() sends 100-continue if necessary
# (without any other movements from aiohttp users)
# and continue reading payload (that is what server
# MUST do if 100-continue is sent)
yield from request.post()
# do "perform request method" as in RFC
result = do_usefull_stuff(request)
return Response(text=result, status=200) |
you can create middleware that for that. |
well, you example already has different use case. so make pull request for your use case. |
Is it supported in aiohttp.web server?
Nginx + Django response looks like this:
Nginx responses with HTTP/1.1 100 Continue first.
The text was updated successfully, but these errors were encountered: