Do SMTP headers (those after the DATA command) now accept Unicode?
Or is the use of encoded-words (RFC 2047) still needed?
Related
I'm developing an API which, given a request-body with certain contents, generates a document that can be in different formats (e.g. pdf, png, etc). Given that the document can be a binary file, the file is base64-encoded and placed within a json response that looks like this:
{
"document": "document base64-encoded"
}
The response might contain other fields but they are not relevant to the question.
My question is:
What is the best way to specify the content-type (e.g. pdf) and the content-encoding (e.g base64) of the field document?
I thought of some options but I would like to hear your recommendation.
My options
Use header parameters Content-Type and Content-Transfer-Encoding: I assume this option would be wrong as these parameters apply to the message itself which in this case is application/json without any encoding.
Specify custom-parameters (e.g. x-document-content-type and x-document-content-tranfer-encoding.
Include such metadata within the response-body like this:
{
"document": {
"content": "document base64-econded",
"type": "pdf",
"econding": "base64"
}
}
Thanks for your input!
There are 2 layers of communication here, each with their own contract/protocol. Your own JSON API protocol, being sent over the HTTP protocol. You should stick to HTTP standards to comply with the contract of that layer, and it is up to you to define the contract of the JSON data.
The mentioned HTTP headers are used to tell the user-agent/client what the MIME-type of the accompanying HTTP body is. This must be application/JSON to comply with the HTTP standard. If you diver from this it will not be valid HTTP traffic anymore and a regular, well configured HTTP client wouldn't be able to consume your API.
The JSON body inside the HTTP message can be filled with whatever you find is necessary for a consumer of your API to use the encoded contents. You are defining your own contract here, so it is really up to your needs and that of the consumers of your api.
Do you use other content encodings as base64? If so, then you can specify the encoding of the data.
Do you provide multiple different file types? Then it's useful to add the content-type of the encoded data. Be aware that the header of the encoded content might already contain information about the type of the contents of the file.
P.s. it would probably be better to provide the "type" as you name it, as a mime-type. This is more common as a known standard for defining content types.
When sending a POST request to a web server, can you specify the Accept header parameter alongside Content-type? As in, I am sending some JSON, so I'll specify that in Content-type, but since I expect a response from the server (perhaps the object that will be added to the database), I would specify that in the Accept parameter?
When sending a POST request to a web server, can you specify the Accept header parameter alongside Content-type?
Yes. Accept is what you will accept in the response. Content-Type is what you are sending in the request. They are entirely independent.
Just learning about JOSE and I understand that JWE is for encryption and JWS is for signing. What I don't seem to be able to find examples of is a payload that is both encrypted and signed.
Let's pretend I have a payload hello world. Is the correct thing to do something like this? JWS(JWE('hello world') with the encrypted JWE as the payload of the JWS?
JSON Web Token (JWT) is an open standard that defines a compact and self-contained way for securely transmitting information between parties as a JSON object. JWT is a generic name for the following types of token:
JSON Web Signature (JWS): The payload is encoded and signed so the integrity of the claims can be verified.
JSON Web Encryption (JWE): They payload is encrypted so the claims are hidden from other parties.
The image was extracted from this page.
Is the correct thing to do something like this? JWS(JWE('hello world') with the encrypted JWE as the payload of the JWS?
It's a nested JWT and its concept is defined in the RFC 7519:
A JWT in which nested signing and/or encryption are employed. In
Nested JWTs, a JWT is used as the payload or plaintext value of an
enclosing JWS or JWE structure, respectively.
You could add a JWE as a claim of a JWS payload, however the other way around is recommended: First sign the message and then encrypt the result, as mentioned in the same document:
11.2. Signing and Encryption Order
While syntactically the signing and encryption operations for Nested
JWTs may be applied in any order, if both signing and encryption are
necessary, normally producers should sign the message and then
encrypt the result (thus encrypting the signature). This prevents
attacks in which the signature is stripped, leaving just an encrypted
message, as well as providing privacy for the signer. Furthermore,
signatures over encrypted text are not considered valid in many
jurisdictions.
I'm using Dev HTTP Client Chrome extension to verify restful URL so i can build C# application that can consume it. I have a trouble with encoding meaning when response is shown inside plugin/browser encoding is not proper, but when i download it with that same plugin and open file with Notepad++ encoding is fine. I'm having same problem with my C# application when reading JSON response from that web service. I also used restclient-ui-3.1 to check data but it behaves same as Chrome plugin, meaning it displays wrong characters in its response body tab.
Obviously web service is sending properly encoded data but i can't manage to read it accordingly on client side. Any hints?
Dev HTTP Client uses Content-Encoding and Content-Type HTTP headers to determine how is response body encoded (e.g. Content-Encoding: gzip) and what representation contains (e.g. Content-Type: application/json; charset=utf-8).
It seems that your webservice is not sending proper HTTP headers. Check them.
I have a client that will be posting large JSON files to an API server. Since the files are so compressable, I would like to gzip them and send the compressed data.
What I would like to know is: What is the best way to signal my intent to the server?
Basically, I want the reverse of Accept-encoding, such that the server would treat the data as only compressed for transport purposes, and automatically decompress the data before interpreting it according to the Content-Type.
This means that I can't set the Content-Type field to application/gzip because it needs to be application/json for the server to understand what the true uncompressed data encoding is.
Content-Transfer-Encoding looks like it would serve my purposes, but it was built with email in mind, and only supports 7bit, quoted-printable, base64, 8bit, and binary.
Does transparent compression/decompression for HTTP transport from client to server exist? And if not, what are the best practices for what I'm trying to achieve?
The "reverse" of the Accept-encoding header is Content-encoding. This signals to the server that the content is gzipped:
Content-encoding: gzip
You're correct that you shouldn't use the Content-type header for this, since the gzip compression is purely a matter of how the request is encoded, not what it represents.