I am calling a SOAP web service as client.
Following is content-type value of response
Content-Type: text/xml
I requested customer to add UTF-8 to response as follow:
Content-Type: text/xml;charset=utf-8
But customer says that it can be from client side. Is this possible? Can I determine content type of server as client?
PS: I noticed that the cited RFC2376 is obsolete by RFC3023 (conservative enough) and then RFC7303 that I'm omitting to evaluate now in involved current use and content, so the relevance of the following might not be that definitive, I'm feeling to delete it.
You have everything formal in RFC2376 XML Media Types: Section 3.1 text/xml Registration
See also Section 6 Examples of that RFC, particularly Section 6.4 text/xml with Omitted Charset
The server side (your customer) is STRONGLY RECOMMENDED to use charset parameter that they are not currently using.
And if charter is omitted XML processors MUST use the default charset value of "us-ascii"
You are right asking the customer to specify charset, the "MUST" in the RFC is a strong requirement that limits also your adaptability from client side when they are not sending us-ascii.
Related
I am working on a project where I need to send requests over email instead of http,
to prevent email servers or clients from messing with the body (especially urls) I have set the Content-Type header in my SMTP request to application/octet-stream instead of text/plain.
The content however is actually plain text so I also specified ;charset=UTF-8.
Looking at RFC it seems that the charset parameter is only allowed for text/* types, however I also found many examples where charset was used with application/* types.
Now I wonder, is application/octet-stream; charset=UTF-8 a valid MIME type?
As the application/octet-stream definition (IANA-RFC) doesn't define a charset for this applicationtype and the definition for application/json (IANA-RFC) a mimetype thats used more often includes a note:
No "charset" parameter is defined for this registration.
Adding one really has no effect on compliant recipients.
I would strongly recommend to assume that the statement not only applies in this special case, but also in other application/* which have no charset defined.
So I can't say if it is valid to pass parameters that aren't defined, but the RFC clearly implies that the charset parameter for application/octet-stream (and other application/* that do not define charset) has no effect.
I have an endpoint which supports POST method with content-type as json(only). But the POST request doesn't return any content in its response body other than status codes. In this scenario, what is the correct behavior?
Client sends POST with Accept header as application/json
Client sends POST with Accept header as application/xml
Should the server return error in case 2?
RFC 7231 describes the semantics of the Accept header
A request without any Accept header field implies that the user agent will accept any media type in response.
If the header field is present in a request and none of the available representations for the response have a media type that is listed as acceptable, the origin server can either honor the header field by sending a 406 (Not Acceptable) response or disregard the header field by treating the response as if it is not subject to content negotiation.
The Accept header provided by the client should probably reflect the context of the request as seen by the client; for instance, a web browser might reasonably use a different Accept header for <img> than for <script>, in each case encouraging the server to provide useful representations.
In the case of a POST, what you are trying to negotiate is the representation of "the status of, or results obtained from, the action", rather than a representation of resource itself.
If the representation of the response is zero bytes long when the media-type is application/json, then I would expect the response to also be zero bytes long when the media-type is application/xml. So it isn't obvious to me to accept one but not the other.
Servers may ignore the Accept header.
If you're not returning anything in your response, it's kind of meaningless. It's up to you to decide whether you want to reject requests with Accept headers or not.
But I think most systems will not reject these requests.
https://datatracker.ietf.org/doc/html/rfc7231#section-5.3.2
A request without any Accept header field implies that the user agent
will accept any media type in response. If the header field is
present in a request and none of the available representations for
the response have a media type that is listed as acceptable, the
origin server can either honor the header field by sending a 406 (Not
Acceptable) response or disregard the header field by treating the
response as if it is not subject to content negotiation.
so either off 2 we can do
We have a REST API to fetch binary files from the server.
The requests look like
GET /documents/e62dd3f6-18b0-4661-92c6-51c7258f9550 HTTP/1.1
Accept: application/octet-stream
For every response indicating an error, we'd like to give a reason in JSON.
The problem is now, that as the response is not of the same content type as the client requested.
But what kind of response should the server produce?
Currently, it responds with a
HTTP / 1.1 406 Not Acceptable
Content-Type: application/json
{
reason: "blabla"
...
}
Which seems wrong to me, as the underlying issue is, that the resource is not existing and not the client requesting the wrong content type.
But the question is, what would be the right way to deal with such situations?
Is it ok, to respond with 404 + application/json although application/octet-stream was requested
Is it ok, to respond with 406 + application/json, as the client did not specify an application/json as an acceptable type
Should spec been extended so that the client should use the q-param - for example, application/octet-stream, application/json;q=0.1
Other options?
If no representation can be found for the requested resource (because it doesn't exist or because the server wishes to "hide" its existence), the server should return 404.
If the client requests a particular representation in the Accept header and the server is not available to provide such representation, the server could either:
Return 406 along with a list of the available representations. (see note** below)
Simply ignore the Accept header and return a default representation of the resource.
See the following quote from the RFC 7231, the document the defines the content and semantics of the HTTP/1.1 protocol:
A request without any Accept header field implies that the user agent will accept any media type in response. If the header field is present in a request and none of the available representations for the response have a media type that is listed as acceptable, the origin server can either honor the header field by sending a 406 (Not Acceptable) response or disregard the header field by treating the response as if it is not subject to content negotiation.
Mozilla also recommends the following regarding 406:
In practice, this error is very rarely used. Instead of responding using this error code, which would be cryptic for the end user and difficult to fix, servers ignore the relevant header and serve an actual page to the user. It is assumed that even if the user won't be completely happy, they will prefer this to an error code.
** Regarding the list of available representations, see this answer.
I would like my REST service to accept CSV files in addition to JSON and XML.
I would accept an HTTP PUT request such as:
PUT /myservice/user
Content-Type: text/csv; charset=utf-8
"tomas";"1980-01-01"
"george";"1981-02-02"
I would like to be able to accept different delimiters and other format options for my CSV file. Preferably without using the querystring, which doesn't seem to be the proper tool for that. I understand I could just invent my own headers such as:
PUT /myservice/user
Content-Type: text/csv; charset=utf-8
CSV-Delimiter: ,
CSV-Options: merge-duplicates, no-header-row
Or maybe I could invent my own parameters to Content-Type if that is allowed (after all it is a part of the content-type just like the charset used):
PUT /myservice/user
Content-Type: text/csv; charset=utf-8; delimiter=,; options=no-header-row
What would be the proper way to handle this? Are there any HTTP-headers conventionally used for this?
For "no-header-row" a parameter already exists: [header="present"|"absent"].
As for adding new parameters to the content-type header:
New parameters SHOULD NOT be defined as a way to introduce new
functionality in types registered in the standards tree, although new
parameters MAY be added to convey additional information that does
not otherwise change existing functionality. An example of this
would be a "revision" parameter to indicate a revision level of an
external specification such as JPEG. Similar behavior is encouraged
for media types registered in the vendor or personal trees but is not
required.
I am trying to find out the range of possible values of Accept and Accept-Contact header fields, but I can't find a complete list in the RFCs. Does anyone know where they are? I often see
Accept: application/sdp;level=1, application/x-private, text/html
but don't know all possible values. More generally, where can I find all possible values of SIP headers?
Thanks,
A lot of sections in the [SIP RFC]1 are based on the [HTTP 1.1 RFC]2 in acknowledgement that the semantics of SIP and HTTP are very similar. The SIP Accept header is a good case in point. The SIP RFC section that deals with the Accept header refers to [H14.1] which translates to section 14.1 in the HTTP 1.1 RFC and which goes into detail about how the Accept header can be used to specify the different types of media that are acceptable in the response.
That all being said in the real World 90% of the time the SIP response media is going to be application/sdp. There will be SIP requests that accept other types of response media but they are not that common.
Bob what you are looking is MIME types.
You find some common MIME type here
http://en.wikipedia.org/wiki/Internet_media_type
A text formation of SIP is derive from HTTP so you can refer HTTP headers also to fine possible values of other headers.
Most headers and parameter with their corresponding RFC are listed: http://www.iana.org/assignments/sip-parameters