Thanks Ralf, In some cases, ACCEPT is not part of the header.. Although this is malformed, many web servers still respond with content_type as the response type as a default behavior. Should we follow the same practice ? Then there is the issue of preferences for media type in the accept ie Accept: text/*, text/html, text/html;level=1, */* have the following precedence: 1) text/html;level=1 2) text/html 3) text/* 4) */* I don't see where the preferences are prioritized in your code... -gary On 3/27/2011 12:15 PM, Ralf Nyren wrote:
Yes, they can indeed by different. You can for instance send your request as text/occi and except the response in text/plain.
As the spec is written right now this is allowed and is in line with RFC2616. Think about how a web-browser POSTs a web-form. The request parameters are typically in "multipart/form-data" while the response is in text/html as dictated by the Accept header.
The occi-py library (http://github.com/nyren/occi-py) supports this nicely.
regards, Ralf
On Sun, 27 Mar 2011 19:14:48 +0200, Gary Mazz <garymazzaferro@gmail.com> wrote:
Hi,
I just realized that Content Type of a HTTP request and the response may be in different formats.. Is this permissible, or should I rephrase, should we make this permissible or force them to be the same ?
gary _______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg