)]}'
{"guidelines/http.rst":[{"author":{"_account_id":12000,"name":"Ian Cordasco","email":"sigmavirus24@gmail.com","username":"sigmavirus24"},"change_message_id":"1757b3f0d7eac832f4b0f488c379bc7cd49126eb","unresolved":false,"context_lines":[{"line_number":21,"context_line":"1xx Informational Codes"},{"line_number":22,"context_line":"~~~~~~~~~~~~~~~~~~~~~~~"},{"line_number":23,"context_line":""},{"line_number":24,"context_line":"These codes are interim responses for communicating server connection status"},{"line_number":25,"context_line":"or request progress. They are not accepted by all clients and **must not**"},{"line_number":26,"context_line":"be sent."},{"line_number":27,"context_line":""}],"source_content_type":"text/x-rst","patch_set":2,"id":"7a016987_aa3012e9","line":24,"updated":"2015-05-18 15:43:09.000000000","message":"It\u0027s a bit disingenous to list these under \"Response Codes\". Responses, per the RFC, have the status code, headers, a body etc. 1xx Codes are literally just that, the code. They\u0027re not fully fledged responses.","commit_id":"44bb2a086d439ad47116a5cb895145425661fe89"},{"author":{"_account_id":7725,"name":"David Stanek","email":"dstanek@dstanek.com","username":"dstanek"},"change_message_id":"b453b108ea25dcff6654908057a351e67fb5181b","unresolved":false,"context_lines":[{"line_number":17,"context_line":"1xx Informational Codes"},{"line_number":18,"context_line":"~~~~~~~~~~~~~~~~~~~~~~~"},{"line_number":19,"context_line":""},{"line_number":20,"context_line":"These codes are interim responses for communicating server connection status"},{"line_number":21,"context_line":"or request progress. They are not accepted by all clients and **must not**"},{"line_number":22,"context_line":"be sent."},{"line_number":23,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"5afe65bd_083ade36","line":20,"updated":"2015-06-02 14:18:26.000000000","message":"That\u0027s unfortunate. I can see things like \u0027100 Continue\u0027 being very useful in certain cases for uploading. Or \u0027101 Switching Protocols\u0027 for realtime monitoring using websockets.","commit_id":"8749418c684c88c91f1b06db522333c051e51800"},{"author":{"_account_id":4190,"name":"lifeless","email":"robertc@robertcollins.net","username":"lifeless"},"change_message_id":"021adcc011024a2df0112267a2830bc864b5fd62","unresolved":false,"context_lines":[{"line_number":17,"context_line":"1xx Informational Codes"},{"line_number":18,"context_line":"~~~~~~~~~~~~~~~~~~~~~~~"},{"line_number":19,"context_line":""},{"line_number":20,"context_line":"These codes are interim responses for communicating server connection status"},{"line_number":21,"context_line":"or request progress. They are not accepted by all clients and **must not**"},{"line_number":22,"context_line":"be sent."},{"line_number":23,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"fa32b979_dab71b83","line":20,"in_reply_to":"3afb71cf_20511a0f","updated":"2015-06-18 21:55:22.000000000","message":"From IRC: it looks like 100 is preserved (though there\u0027s precious little point since it no longer causes HOL blocking anywhere) :- the argument as I follow it was gateway sanity. 101 is dropped from h/2.\n\nThat said, this advice is problematic.","commit_id":"8749418c684c88c91f1b06db522333c051e51800"},{"author":{"_account_id":12000,"name":"Ian Cordasco","email":"sigmavirus24@gmail.com","username":"sigmavirus24"},"change_message_id":"1b9d8d33c98d506f67d9839a7138744775355dba","unresolved":false,"context_lines":[{"line_number":17,"context_line":"1xx Informational Codes"},{"line_number":18,"context_line":"~~~~~~~~~~~~~~~~~~~~~~~"},{"line_number":19,"context_line":""},{"line_number":20,"context_line":"These codes are interim responses for communicating server connection status"},{"line_number":21,"context_line":"or request progress. They are not accepted by all clients and **must not**"},{"line_number":22,"context_line":"be sent."},{"line_number":23,"context_line":""}],"source_content_type":"text/x-rst","patch_set":3,"id":"3afb71cf_20511a0f","line":20,"in_reply_to":"5afe65bd_083ade36","updated":"2015-06-07 16:20:26.000000000","message":"It\u0027s also something most servers don\u0027t use because support was initially so bad for these codes anyway. In fact, httplib/http.client can\u0027t support the 1xx codes. It doesn\u0027t break because of them, but it simply swallows them and ignores them.\n\nThe RFC for HTTP says that when uploading a large amount of data you should send \n\n    Expect: 100-continue\n\nIn the headers and wait for either \"100 Continue\" to be returned by the server or *a reasonable period of time*. In Python, that \"reasonable period of time\" is used and is the time it takes for your CPU to execute the instructions between sending the headers and sending the data.\n\nhttplibplus or httplib2 or one (and exactly one) of those other fork/rewrites of httplib supports 100 codes, but we\u0027ve already committed to using requests which can\u0027t support it until httplib does or until we can replace httplib. (And yes, we explored that other library and no it doesn\u0027t work out.)\n\nFurther, the last draft I remember reading of the HTTP/2 spec eliminated 100 status codes. I forget if this changed after that, but the fact that the HTTPBis WG decided it was a good idea to drop them indicates that they\u0027re probably not widely used (or supported) in the first place.","commit_id":"8749418c684c88c91f1b06db522333c051e51800"},{"author":{"_account_id":4190,"name":"lifeless","email":"robertc@robertcollins.net","username":"lifeless"},"change_message_id":"021adcc011024a2df0112267a2830bc864b5fd62","unresolved":false,"context_lines":[{"line_number":19,"context_line":""},{"line_number":20,"context_line":"These codes are interim responses for communicating server connection status"},{"line_number":21,"context_line":"or request progress. They are not accepted by all clients and **must not**"},{"line_number":22,"context_line":"be sent."},{"line_number":23,"context_line":""},{"line_number":24,"context_line":"2xx Success Codes"},{"line_number":25,"context_line":"~~~~~~~~~~~~~~~~~"}],"source_content_type":"text/x-rst","patch_set":3,"id":"fa32b979_fa33ff11","line":22,"updated":"2015-06-18 21:55:22.000000000","message":"So, this is problematic - it will cause stalls on uploads for HTTP/1.1 clients that sent an Expect 100 header.\n\nThe right thing to do in OpenStack is:\n - if the header is received, send a 100 or 4xx immediately.\n - if the header isn\u0027t received, do not send a 100.\n\nWhy are we suggesting non-HTTP compliant behaviour?","commit_id":"8749418c684c88c91f1b06db522333c051e51800"},{"author":{"_account_id":261,"name":"Salvatore Orlando","email":"salv.orlando@gmail.com","username":"salvatore-orlando"},"change_message_id":"e44a9d2024155509a2749c6ac4f2dedfd3b848ea","unresolved":false,"context_lines":[{"line_number":19,"context_line":""},{"line_number":20,"context_line":"These codes are interim responses for communicating server connection status"},{"line_number":21,"context_line":"or request progress. They are not accepted by all clients and **must not**"},{"line_number":22,"context_line":"be sent."},{"line_number":23,"context_line":""},{"line_number":24,"context_line":"2xx Success Codes"},{"line_number":25,"context_line":"~~~~~~~~~~~~~~~~~"}],"source_content_type":"text/x-rst","patch_set":3,"id":"fa32b979_1b8a8c64","line":22,"in_reply_to":"fa32b979_9d3f4db3","updated":"2015-06-24 20:03:08.000000000","message":"If the origin server responds to requests with a \"100-continue\u0027 expectation header with a 400 error (or any other appropriate code), would that be HTTP/1.1 compliant? An error code is a final status code.","commit_id":"8749418c684c88c91f1b06db522333c051e51800"},{"author":{"_account_id":4190,"name":"lifeless","email":"robertc@robertcollins.net","username":"lifeless"},"change_message_id":"9648874cebe21517f4bdea2d9870022eeb764c68","unresolved":false,"context_lines":[{"line_number":19,"context_line":""},{"line_number":20,"context_line":"These codes are interim responses for communicating server connection status"},{"line_number":21,"context_line":"or request progress. They are not accepted by all clients and **must not**"},{"line_number":22,"context_line":"be sent."},{"line_number":23,"context_line":""},{"line_number":24,"context_line":"2xx Success Codes"},{"line_number":25,"context_line":"~~~~~~~~~~~~~~~~~"}],"source_content_type":"text/x-rst","patch_set":3,"id":"fa32b979_9d3f4db3","line":22,"in_reply_to":"fa32b979_fa33ff11","updated":"2015-06-18 21:58:38.000000000","message":"Specifically, I quote from the end of https://tools.ietf.org/html/rfc7231#section-5.1.1\n\n   An origin server MUST, upon receiving an HTTP/1.1 (or later)\n   request-line and a complete header section that contains a\n   100-continue expectation and indicates a request message body will\n   follow, either send an immediate response with a final status code,\n   if that status can be determined by examining just the request-line\n   and header fields, or send an immediate 100 (Continue) response to\n   encourage the client to send the request\u0027s message body.  The origin\n   server MUST NOT wait for the message body before sending the 100\n   (Continue) response.\n\nThe proposed advice is nonconformant with HTTP/1.1, and we should stop using 1.1 as our version line if we\u0027re going to do this.","commit_id":"8749418c684c88c91f1b06db522333c051e51800"}]}
