)]}'
{"guidelines/headers.rst":[{"author":{"_account_id":7,"name":"Jay Pipes","email":"jaypipes@gmail.com","username":"jaypipes"},"change_message_id":"9342d6f7b9a21ee9c687667f26ae93c26fe28e61","unresolved":false,"context_lines":[{"line_number":68,"context_line":""},{"line_number":69,"context_line":".. note:: The use of microversion headers here is for the sake of a"},{"line_number":70,"context_line":"   concrete illustration. Microversion headers are already in use in"},{"line_number":71,"context_line":"   the second form and will not change."},{"line_number":72,"context_line":""},{"line_number":73,"context_line":"At first glance these header name and value pairs convey the same"},{"line_number":74,"context_line":"information, with the second option being a bit easier to parse on"}],"source_content_type":"text/x-rst","patch_set":1,"id":"bae84128_50dc0ae4","line":71,"updated":"2016-02-21 18:39:16.000000000","message":"Technically, the form used for the compute API microversion header is unfortunately this:\n\n OpenStack-Nova-API-Version: 2.42\n\nhttps://github.com/openstack/nova/blob/master/nova/api/openstack/rest_api_version_history.rst#21\n\nwhich uses the project name instead of the service type. Same for Ironic.","commit_id":"c01f495c7658c80727dcff1efc30e8720a2b05e3"},{"author":{"_account_id":11564,"name":"Chris Dent","email":"cdent@anticdent.org","username":"chdent"},"change_message_id":"f2c3429188ad2614476ce9f29ea2a657f4e7c3f7","unresolved":false,"context_lines":[{"line_number":68,"context_line":""},{"line_number":69,"context_line":".. note:: The use of microversion headers here is for the sake of a"},{"line_number":70,"context_line":"   concrete illustration. Microversion headers are already in use in"},{"line_number":71,"context_line":"   the second form and will not change."},{"line_number":72,"context_line":""},{"line_number":73,"context_line":"At first glance these header name and value pairs convey the same"},{"line_number":74,"context_line":"information, with the second option being a bit easier to parse on"}],"source_content_type":"text/x-rst","patch_set":1,"id":"bae84128_707dceb0","line":71,"in_reply_to":"bae84128_50dc0ae4","updated":"2016-02-21 18:47:57.000000000","message":"We\u0027ve got another guideline in flight, which I was assuming would merge before this one, which states that the correct form is *-compute-* so I thought it better to use that form as it is more futureproof.\n\nOf course if we get a groundswell of \"it would be totes ossum if we just went ahead and made the leap to more better\" then that other guideline will need to be updated and this one can reflect the ancient history form.\n\nFurther of[f] course: My intent was to try to use a different example than microversions as that seemed deliberately confusing, but I couldn\u0027t think of a better one.","commit_id":"c01f495c7658c80727dcff1efc30e8720a2b05e3"},{"author":{"_account_id":2506,"name":"devdatta-kulkarni","email":"kulkarni.devdatta@gmail.com","username":"devdatta-kulkarni"},"change_message_id":"e9ce8d8306b4232806844e99113ad60506c0e8cc","unresolved":false,"context_lines":[{"line_number":76,"context_line":"the server side. However consider the following problems when using"},{"line_number":77,"context_line":"the second form:"},{"line_number":78,"context_line":""},{"line_number":79,"context_line":"* A new header is needed every time there is a new service."},{"line_number":80,"context_line":"* It violates the principle that in key-value based data structures"},{"line_number":81,"context_line":"  the key should be an accessor only, that is: It should be opaque"},{"line_number":82,"context_line":"  and generic."}],"source_content_type":"text/x-rst","patch_set":2,"id":"5aef4532_0079d2fc","line":79,"updated":"2016-03-07 14:55:55.000000000","message":"On the other hand, having service name/type in the header name allows specifying versions of multiple services in a straightforward manner, if required. \n\nExample:\nOpenStack-Compute-API-Version: 2.1\nOpenStack-Storage-API-Version: 2.2\n\nHow might this be possible if we have a generic header like OpenStack-API-Version?","commit_id":"a370db6761ea0c8b1f918f5bbbc0c8fd53f537f2"},{"author":{"_account_id":11564,"name":"Chris Dent","email":"cdent@anticdent.org","username":"chdent"},"change_message_id":"4f97162eb35ccda3a83c1f331d7fa6fda9f3ffd8","unresolved":false,"context_lines":[{"line_number":76,"context_line":"the server side. However consider the following problems when using"},{"line_number":77,"context_line":"the second form:"},{"line_number":78,"context_line":""},{"line_number":79,"context_line":"* A new header is needed every time there is a new service."},{"line_number":80,"context_line":"* It violates the principle that in key-value based data structures"},{"line_number":81,"context_line":"  the key should be an accessor only, that is: It should be opaque"},{"line_number":82,"context_line":"  and generic."}],"source_content_type":"text/x-rst","patch_set":2,"id":"5aef4532_aac43892","line":79,"in_reply_to":"5aef4532_0079d2fc","updated":"2016-03-07 15:28:39.000000000","message":"Either of these are correct:\n\n    OpenStack-API-Version: compute 2.1\n    OpenStack-API-Version: storage 2.2\n\nor\n\n    OpenStack-API-Version: compute 2.1,storage 2.2","commit_id":"a370db6761ea0c8b1f918f5bbbc0c8fd53f537f2"},{"author":{"_account_id":2506,"name":"devdatta-kulkarni","email":"kulkarni.devdatta@gmail.com","username":"devdatta-kulkarni"},"change_message_id":"e9ce8d8306b4232806844e99113ad60506c0e8cc","unresolved":false,"context_lines":[{"line_number":80,"context_line":"* It violates the principle that in key-value based data structures"},{"line_number":81,"context_line":"  the key should be an accessor only, that is: It should be opaque"},{"line_number":82,"context_line":"  and generic."},{"line_number":83,"context_line":"* If CORS[1]_ middleware is being used, it needs to be configured to"},{"line_number":84,"context_line":"  allow a multitude of headers instead of a generic one."},{"line_number":85,"context_line":"* Generic library code (in either the client or the server) that is"},{"line_number":86,"context_line":"  supposed to deal with this class of header has to construct or parse"}],"source_content_type":"text/x-rst","patch_set":2,"id":"5aef4532_e0678623","line":83,"updated":"2016-03-07 14:55:55.000000000","message":"Not clear what is the issue. \n\nAre you saying that the CORS headers (Access-Control-Allow-Origin, Access-Control-Allow-Methods, Access-Control-Allow-Headers, Access-Control-Max-Age) would not be possible to be used if we were to use the second form? Why?","commit_id":"a370db6761ea0c8b1f918f5bbbc0c8fd53f537f2"},{"author":{"_account_id":2506,"name":"devdatta-kulkarni","email":"kulkarni.devdatta@gmail.com","username":"devdatta-kulkarni"},"change_message_id":"61740d8d72e683c00af49cc7e16b698e045d4b0e","unresolved":false,"context_lines":[{"line_number":80,"context_line":"* It violates the principle that in key-value based data structures"},{"line_number":81,"context_line":"  the key should be an accessor only, that is: It should be opaque"},{"line_number":82,"context_line":"  and generic."},{"line_number":83,"context_line":"* If CORS[1]_ middleware is being used, it needs to be configured to"},{"line_number":84,"context_line":"  allow a multitude of headers instead of a generic one."},{"line_number":85,"context_line":"* Generic library code (in either the client or the server) that is"},{"line_number":86,"context_line":"  supposed to deal with this class of header has to construct or parse"}],"source_content_type":"text/x-rst","patch_set":2,"id":"5aef4532_aa89d8cc","line":83,"in_reply_to":"5aef4532_6aca30a3","updated":"2016-03-07 15:40:10.000000000","message":"Thanks for the clarification.","commit_id":"a370db6761ea0c8b1f918f5bbbc0c8fd53f537f2"},{"author":{"_account_id":11564,"name":"Chris Dent","email":"cdent@anticdent.org","username":"chdent"},"change_message_id":"4f97162eb35ccda3a83c1f331d7fa6fda9f3ffd8","unresolved":false,"context_lines":[{"line_number":80,"context_line":"* It violates the principle that in key-value based data structures"},{"line_number":81,"context_line":"  the key should be an accessor only, that is: It should be opaque"},{"line_number":82,"context_line":"  and generic."},{"line_number":83,"context_line":"* If CORS[1]_ middleware is being used, it needs to be configured to"},{"line_number":84,"context_line":"  allow a multitude of headers instead of a generic one."},{"line_number":85,"context_line":"* Generic library code (in either the client or the server) that is"},{"line_number":86,"context_line":"  supposed to deal with this class of header has to construct or parse"}],"source_content_type":"text/x-rst","patch_set":2,"id":"5aef4532_6aca30a3","line":83,"in_reply_to":"5aef4532_e0678623","updated":"2016-03-07 15:28:39.000000000","message":"No, I\u0027m saying that Access-Control-Allow-Headers and Access-Control-Request-Headers have to be managed for each service instead of just for the one header: \"OpenStack-API-Version\".\n\nIf we have CORS middlware running in front of multiple endpoints (which would be a completely legitimate configuration) we don\u0027t want that middleware to have to configure itself for many headers. For example the lists of allowed headers here would have to be quite long if multiple services were behind the middleware:\n\nhttps://github.com/openstack/ceilometer/blob/c8dd0947f152c88df2b65f009337affbf38add72/etc/ceilometer/api_paste.ini#L22-L23","commit_id":"a370db6761ea0c8b1f918f5bbbc0c8fd53f537f2"}]}