HTTP Header Serialization Format, use of Attribute header
Hi, Reading the updated spec on Http Header Rendering [1] I see you have changed the way attributes are represented in the HTTP header. In the latest docbook spec OCCI resource attributes are specified using the "Attribute" header, e.g.: GET /compute/xxx HTTP/1.0 HTTP/1.0 200 OK Attribute: occi.compute.speed=2.0 Attribute: occi.compute.memory=1.0 In the latest spec however it would look like this instead: HTTP/1.0 200 OK occi.compute.speed: 2.0 occi.compute.memory: 1.0 What is the motivation behind this change? I believe the Attribute header is a much more clean approach since it does not pollute the HTTP header namespace with (perhaps) arbitrary names (you have to consider vendor extensions as well). regards, Ralf [1] http://forge.ogf.org/sf/wiki/do/viewPage/projects.occi-wg/wiki/HTTPHeaderRen...
What's in the doc book version is not the current version. Speaking from an implementer's point of view (mine) removal of "Attribute:" has made parsing of header key/values easier. Personally, I have no strong tie to either approach. Andy -----Original Message----- From: occi-wg-bounces@ogf.org [mailto:occi-wg-bounces@ogf.org] On Behalf Of Ralf Nyren Sent: Wednesday, August 11, 2010 11:27 AM To: occi-wg@ogf.org Subject: [occi-wg] HTTP Header Serialization Format, use of Attribute header Hi, Reading the updated spec on Http Header Rendering [1] I see you have changed the way attributes are represented in the HTTP header. In the latest docbook spec OCCI resource attributes are specified using the "Attribute" header, e.g.: GET /compute/xxx HTTP/1.0 HTTP/1.0 200 OK Attribute: occi.compute.speed=2.0 Attribute: occi.compute.memory=1.0 In the latest spec however it would look like this instead: HTTP/1.0 200 OK occi.compute.speed: 2.0 occi.compute.memory: 1.0 What is the motivation behind this change? I believe the Attribute header is a much more clean approach since it does not pollute the HTTP header namespace with (perhaps) arbitrary names (you have to consider vendor extensions as well). regards, Ralf [1] http://forge.ogf.org/sf/wiki/do/viewPage/projects.occi-wg/wiki/HTTPHeaderRen... _______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg ------------------------------------------------------------- Intel Ireland Limited (Branch) Collinstown Industrial Park, Leixlip, County Kildare, Ireland Registered Number: E902934 This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.
On Wed, 11 Aug 2010 12:30:41 +0200, Edmonds, AndrewX <andrewx.edmonds@intel.com> wrote:
Speaking from an implementer's point of view (mine) removal of "Attribute:" has made parsing of header key/values easier. Personally, I have no strong tie to either approach.
I would beg to differ on that point :) I am also an implementor and using the Attribute header I can just reuse the same base functionality as for parsing Category and Link headers. Since RFC2616 says multiple header values can be represented both as comma-separated lists and multiple header lines the code for parsing this with proper escaping of quotes etc will have to be present anyway. regards, Ralf
:-) Be aware of the multiple header keys aspect e.g. ... Attribute: occi.compute.cores=2 Attribute: occi.compute.speed=2.4 ... My experience is that many web frameworks do not observe 2616 correctly. Taking tomcat and associated frameworks; if I send such a request as above the only header that I will receive is the last one, not all. Web.py also exhibits this same behavior. As a result you will always have to formulate your request as such: Attribute: occi.compute.cores=2, occi.compute.speed=2.4 This particular issue is not a problem using a request like: ... occi.compute.cores=2 occi.compute.speed=2.4 ... However the issue remains for Link and Category headers. Andy -----Original Message----- From: Ralf Nyren [mailto:ralf@nyren.net] Sent: Wednesday, August 11, 2010 11:43 AM To: Edmonds, AndrewX; occi-wg@ogf.org Subject: Re: [occi-wg] HTTP Header Serialization Format, use of Attribute header On Wed, 11 Aug 2010 12:30:41 +0200, Edmonds, AndrewX <andrewx.edmonds@intel.com> wrote:
Speaking from an implementer's point of view (mine) removal of "Attribute:" has made parsing of header key/values easier. Personally, I have no strong tie to either approach.
I would beg to differ on that point :) I am also an implementor and using the Attribute header I can just reuse the same base functionality as for parsing Category and Link headers. Since RFC2616 says multiple header values can be represented both as comma-separated lists and multiple header lines the code for parsing this with proper escaping of quotes etc will have to be present anyway. regards, Ralf ------------------------------------------------------------- Intel Ireland Limited (Branch) Collinstown Industrial Park, Leixlip, County Kildare, Ireland Registered Number: E902934 This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.
Yes, I am aware of the problems and thus currently only use the comma-separated list format for outgoing data. But as you said we still have this problem for Category and Link headers in any case so I do not see why the specification would try to accommodate the web framework, etc problems for just attributes. I mean, the whole bootstrap/discovery process depends on the ability to send multiple Category headers. A more solid argument as I see it is one of robustness. With the Attribute header we tag all the supplied values as being attributes and nothing else. For a client this means it can display unrecognized (vendor) attributes to the user and a server can respond with an appropriate error message for any attributes it does not support. Without the Attribute header unrecognized attributes would just be silently discarded. regards, Ralf On Wed, 11 Aug 2010 12:52:51 +0200, Edmonds, AndrewX <andrewx.edmonds@intel.com> wrote:
:-)
Be aware of the multiple header keys aspect e.g.
... Attribute: occi.compute.cores=2 Attribute: occi.compute.speed=2.4 ...
My experience is that many web frameworks do not observe 2616 correctly. Taking tomcat and associated frameworks; if I send such a request as above the only header that I will receive is the last one, not all. Web.py also exhibits this same behavior. As a result you will always have to formulate your request as such:
Attribute: occi.compute.cores=2, occi.compute.speed=2.4
This particular issue is not a problem using a request like:
... occi.compute.cores=2 occi.compute.speed=2.4 ...
However the issue remains for Link and Category headers.
Andy
-----Original Message----- From: Ralf Nyren [mailto:ralf@nyren.net] Sent: Wednesday, August 11, 2010 11:43 AM To: Edmonds, AndrewX; occi-wg@ogf.org Subject: Re: [occi-wg] HTTP Header Serialization Format, use of Attribute header
On Wed, 11 Aug 2010 12:30:41 +0200, Edmonds, AndrewX <andrewx.edmonds@intel.com> wrote:
Speaking from an implementer's point of view (mine) removal of "Attribute:" has made parsing of header key/values easier. Personally, I have no strong tie to either approach.
I would beg to differ on that point :) I am also an implementor and using the Attribute header I can just reuse the same base functionality as for parsing Category and Link headers. Since RFC2616 says multiple header values can be represented both as comma-separated lists and multiple header lines the code for parsing this with proper escaping of quotes etc will have to be present anyway.
regards, Ralf ------------------------------------------------------------- Intel Ireland Limited (Branch) Collinstown Industrial Park, Leixlip, County Kildare, Ireland Registered Number: E902934
This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.
Good points and no objections from me :-) -----Original Message----- From: Ralf Nyren [mailto:ralf@nyren.net] Sent: Wednesday, August 11, 2010 12:14 PM To: Edmonds, AndrewX; occi-wg@ogf.org Subject: Re: [occi-wg] HTTP Header Serialization Format, use of Attribute header Yes, I am aware of the problems and thus currently only use the comma-separated list format for outgoing data. But as you said we still have this problem for Category and Link headers in any case so I do not see why the specification would try to accommodate the web framework, etc problems for just attributes. I mean, the whole bootstrap/discovery process depends on the ability to send multiple Category headers. A more solid argument as I see it is one of robustness. With the Attribute header we tag all the supplied values as being attributes and nothing else. For a client this means it can display unrecognized (vendor) attributes to the user and a server can respond with an appropriate error message for any attributes it does not support. Without the Attribute header unrecognized attributes would just be silently discarded. regards, Ralf ------------------------------------------------------------- Intel Ireland Limited (Branch) Collinstown Industrial Park, Leixlip, County Kildare, Ireland Registered Number: E902934 This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.
If there are no objections I say we reintroduce the Attribute header. I can update the wiki page (HTTPHeaderRendering) accordingly. I then suggest we use it as a basis for discussion at the conference call next Wednesday and if you decide to decline the change we can just revert back to the old version. regards, Ralf On Wed, 11 Aug 2010 13:21:00 +0200, Edmonds, AndrewX <andrewx.edmonds@intel.com> wrote:
Good points and no objections from me :-)
-----Original Message----- From: Ralf Nyren [mailto:ralf@nyren.net] Sent: Wednesday, August 11, 2010 12:14 PM To: Edmonds, AndrewX; occi-wg@ogf.org Subject: Re: [occi-wg] HTTP Header Serialization Format, use of Attribute header
Yes, I am aware of the problems and thus currently only use the comma-separated list format for outgoing data.
But as you said we still have this problem for Category and Link headers in any case so I do not see why the specification would try to accommodate the web framework, etc problems for just attributes. I mean, the whole bootstrap/discovery process depends on the ability to send multiple Category headers.
A more solid argument as I see it is one of robustness. With the Attribute header we tag all the supplied values as being attributes and nothing else. For a client this means it can display unrecognized (vendor) attributes to the user and a server can respond with an appropriate error message for any attributes it does not support. Without the Attribute header unrecognized attributes would just be silently discarded.
regards, Ralf
------------------------------------------------------------- Intel Ireland Limited (Branch) Collinstown Industrial Park, Leixlip, County Kildare, Ireland Registered Number: E902934
This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.
Go for it Ralf and we'll put it as a discussion topic for next week! :-) On 13 Aug 2010, at 11:15, Ralf Nyren wrote:
If there are no objections I say we reintroduce the Attribute header.
I can update the wiki page (HTTPHeaderRendering) accordingly. I then suggest we use it as a basis for discussion at the conference call next Wednesday and if you decide to decline the change we can just revert back to the old version.
regards, Ralf
On Wed, 11 Aug 2010 13:21:00 +0200, Edmonds, AndrewX <andrewx.edmonds@intel.com> wrote:
Good points and no objections from me :-)
-----Original Message----- From: Ralf Nyren [mailto:ralf@nyren.net] Sent: Wednesday, August 11, 2010 12:14 PM To: Edmonds, AndrewX; occi-wg@ogf.org Subject: Re: [occi-wg] HTTP Header Serialization Format, use of Attribute header
Yes, I am aware of the problems and thus currently only use the comma-separated list format for outgoing data.
But as you said we still have this problem for Category and Link headers in any case so I do not see why the specification would try to accommodate the web framework, etc problems for just attributes. I mean, the whole bootstrap/discovery process depends on the ability to send multiple Category headers.
A more solid argument as I see it is one of robustness. With the Attribute header we tag all the supplied values as being attributes and nothing else. For a client this means it can display unrecognized (vendor) attributes to the user and a server can respond with an appropriate error message for any attributes it does not support. Without the Attribute header unrecognized attributes would just be silently discarded.
regards, Ralf
------------------------------------------------------------- Intel Ireland Limited (Branch) Collinstown Industrial Park, Leixlip, County Kildare, Ireland Registered Number: E902934
This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.
_______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg
Hi all, I have updated the HTTP Header Rendering document re-introducing the Attribute header. I did also add more specific stuff on the allowed header format with references to RFC2616 etc. Most notably the use of multiple headers since this is likely to be a real issue for many implementors. I am looking forward to your comments. regards, Ralf
Andy, I continue this thread to discuss your comments in the wiki. Cut-n-paste from wiki: "HTTP header field values which contain separator characters MUST be properly quoted according to RFC 2616. Is this necessary? It could be assumed that the value of the header is the text immediately following the '=' character. Would be useful to have a list of these separator characters" Yes, it is necessary. If you have an attribute containing a comma (",") you would break the comma-separated list representation of HTTP header field values. According to RFC2616 the following two examples are be equivalent. Attribute: foo="bar,foo" Attribute: key=value Attribute: foo="bar,foo", key=value The list of separators are specified in RFC2616. regards, Ralf
Cheers Ralf :-) As we use '.' as a character to denote namespace delineation we should also add this to the list of separators, incl. 2616. Andy -----Original Message----- From: Ralf Nyren [mailto:ralf@nyren.net] Sent: Monday, August 16, 2010 3:12 PM To: Andy Edmonds Cc: Edmonds, AndrewX; occi-wg@ogf.org Subject: Re: [occi-wg] HTTP Header Serialization Format, use of Attribute header Andy, I continue this thread to discuss your comments in the wiki. Cut-n-paste from wiki: "HTTP header field values which contain separator characters MUST be properly quoted according to RFC 2616. Is this necessary? It could be assumed that the value of the header is the text immediately following the '=' character. Would be useful to have a list of these separator characters" Yes, it is necessary. If you have an attribute containing a comma (",") you would break the comma-separated list representation of HTTP header field values. According to RFC2616 the following two examples are be equivalent. Attribute: foo="bar,foo" Attribute: key=value Attribute: foo="bar,foo", key=value The list of separators are specified in RFC2616. regards, Ralf ------------------------------------------------------------- Intel Ireland Limited (Branch) Collinstown Industrial Park, Leixlip, County Kildare, Ireland Registered Number: E902934 This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.
On Mon, 16 Aug 2010 16:19:05 +0200, Edmonds, AndrewX <andrewx.edmonds@intel.com> wrote:
As we use '.' as a character to denote namespace delineation we should also add this to the list of separators, incl. 2616.
We could but I do not see why that would be necessary. The comma separates field values and the equal sign separate attribute name from attribute value. So from the parser's perspective only those two characters need be quoted. However, for consistency I thought it to be a good idea to include the full separator list from RFC2616. But you maybe have an example where the use of an unquoted '.' would confuse the parser? I do however think we should add a policy on attribute names. Both valid characters etc but also the naming policy because the namespace is shared by all categories. This could perhaps go into the Extensions document we talked about. regards, Ralf
My reasoning is 1) consistency and 2) in the examples a float value of 2.0 is shown as being quoted. Perhaps this is unintended and should be unquoted. If so then 1) is a minor consideration and '.' does not need be included in the separator list, unless for a want of consistency. Andy -----Original Message----- From: Ralf Nyren [mailto:ralf@nyren.net] Sent: Monday, August 16, 2010 3:32 PM To: Edmonds, AndrewX; Andy Edmonds Cc: occi-wg@ogf.org Subject: Re: [occi-wg] HTTP Header Serialization Format, use of Attribute header On Mon, 16 Aug 2010 16:19:05 +0200, Edmonds, AndrewX <andrewx.edmonds@intel.com> wrote:
As we use '.' as a character to denote namespace delineation we should also add this to the list of separators, incl. 2616.
We could but I do not see why that would be necessary. The comma separates field values and the equal sign separate attribute name from attribute value. So from the parser's perspective only those two characters need be quoted. However, for consistency I thought it to be a good idea to include the full separator list from RFC2616. But you maybe have an example where the use of an unquoted '.' would confuse the parser? I do however think we should add a policy on attribute names. Both valid characters etc but also the naming policy because the namespace is shared by all categories. This could perhaps go into the Extensions document we talked about. regards, Ralf ------------------------------------------------------------- Intel Ireland Limited (Branch) Collinstown Industrial Park, Leixlip, County Kildare, Ireland Registered Number: E902934 This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.
On Tue, 17 Aug 2010 01:02:32 +0200, Edmonds, AndrewX <andrewx.edmonds@intel.com> wrote:
My reasoning is 1) consistency and 2) in the examples a float value of 2.0 is shown as being quoted. Perhaps this is unintended and should be unquoted. If so then 1) is a minor consideration and '.' does not need be included in the separator list, unless for a want of consistency.
Good and important point. Examples must be consistent and you are right, no need to quote the float values. I have updated the examples to include a quoted title attribute which should make things clear. regards, Ralf
On Wed, 2010-08-11 at 11:52 +0100, Edmonds, AndrewX wrote:
Attribute: occi.compute.speed=2.4 ...
My experience is that many web frameworks do not observe 2616 correctly. Taking tomcat and associated frameworks; if I send such a request as above the only header that I will receive is the last one, not all. Web.py also exhibits this same behavior. As a result you will always have to formulate your request as such:
web.py doesn't do this for the following example...Only Categories and Links would ned to be listed.... -Thijs
Attribute: occi.compute.cores=2, occi.compute.speed=2.4
This particular issue is not a problem using a request like:
... occi.compute.cores=2 occi.compute.speed=2.4 ...
However the issue remains for Link and Category headers.
Andy -- Thijs Metsch Senior Software Engineer Grid and Cloud Technology Platform Computing GmbH Europaring 60 D-40878 Ratingen http://www.platform.com
http://www.nohuddleoffense.de/ - http://www.twitter.com/befreax
forget it...I just misinterpretted your statement...*sorry* -----Original Message----- From: occi-wg-bounces@ogf.org on behalf of Thijs Metsch Sent: Wed 11-Aug-10 14:13 To: Edmonds, AndrewX Cc: occi-wg@ogf.org Subject: Re: [occi-wg] HTTP Header Serialization Format, use of Attribute header On Wed, 2010-08-11 at 11:52 +0100, Edmonds, AndrewX wrote:
Attribute: occi.compute.speed=2.4 ...
My experience is that many web frameworks do not observe 2616 correctly. Taking tomcat and associated frameworks; if I send such a request as above the only header that I will receive is the last one, not all. Web.py also exhibits this same behavior. As a result you will always have to formulate your request as such:
web.py doesn't do this for the following example...Only Categories and Links would ned to be listed.... -Thijs
Attribute: occi.compute.cores=2, occi.compute.speed=2.4
This particular issue is not a problem using a request like:
... occi.compute.cores=2 occi.compute.speed=2.4 ...
However the issue remains for Link and Category headers.
Andy -- Thijs Metsch Senior Software Engineer Grid and Cloud Technology Platform Computing GmbH Europaring 60 D-40878 Ratingen http://www.platform.com
http://www.nohuddleoffense.de/ - http://www.twitter.com/befreax _______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg
participants (4)
-
Andy Edmonds -
Edmonds, AndrewX -
Ralf Nyren -
Thijs Metsch