I remember some blog saying that response header Content-Disposition may cause security threats and the user's privacy is vulnerable. I also remember it stating that the header is not part of the HTTP Specs but I just can not find the blog or any proper article that why it is said so?
Please provide a simple code example to demo the same.
Content-Disposition is an HTTP header field; consult the IANA header field registry for the RFC definining it (and, hint: that RFC contains a section called "Security Considerations").
Related
For example, when you perform an call from summary api of wikipedia, there is this header in the request
accept:application/json; charset=utf-8; profile="https://www.mediawiki.org/wiki/Specs/Summary/1.3.7"
What is the purpose of this particular bit. I would like to understand since the value changes when you, for example, use the VisualEditor or access the api with different mean.
profile="https://www.mediawiki.org/wiki/Specs/Summary/1.3.7"
This specifies the response format and provides convenient access to a human-readable documentation.
The URL in your header leads to nowhere, but https://www.mediawiki.org/wiki/Specs/Summary/1.3.0 does exist and is probably valid for 1.3.7 as well.
I have seen the HTTP headers of Content-Language and Accept-Language, could someone explain what these are for and the difference between them? I have a multilingual site and wondering should I be setting both to the sites current selected language, by the user.
Content-Language, an entity header, is used to describe the language(s) intended for the audience, so that it allows a user to differentiate according to the users' own preferred language. Entity headers are used in both, HTTP requests and responses.1
Accept-Language, a request HTTP header, advertises which languages the client is able to understand, and which locale variant is preferred.2 There can be multiple languages, each with an optional weight or 'quality' value. For example:
Accept-Language: da, en-GB;q=0.8, en;q=0.7
(The default weight is 1, so this is equivalent to da;q=1, en-GB;q=0.8, en;q=0.7).
You're going to have to parse the values and weights to see if an appropriate translation is available, and provide the user the translation in the highest preferred language weight.
It is recommended you give the users an alternative, such as a cookie set value, to force a certain language for your site. This is because some users may want to see your site in a certain language, without changing their language acceptance preferences.
Content-Language is the language of the page you're serving.
Accept-Language is a list of languages you PREFER to accept.
Content-Language describes the language that a particular piece of content is intended for. Accept-Language is the list of languages that a user agent wants content in. The best way to think of this is that Content-Language describes content and Accept-Language conveys a preference.
The Content-Language entity-header field describes the natural language(s) of the intended audience for the enclosed entity. Note that this might not be equivalent to all the languages used within the entity-body.
The Accept-Language request-header field restricts the set of natural languages that are preferred as a response to the request
http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html
The Content-Language entity header is used to describe the language(s) intended for the audience, so that it allows a user to differentiate according to the users' own preferred language.
Header type Entity header
Forbidden header name no
CORS-safelisted response-header yes
CORS-safelisted request-header yes
— MDN Web Reference - HTTP Headers - Content-Language
The Accept-Language request HTTP header advertises which languages the client is able to understand, and which locale variant is preferred. (By languages, we mean natural languages, such as English, and not programming languages.)
Header type Request header
Forbidden header name no
CORS-safelisted request-header yes
— MDN Web Reference - HTTP Headers - Accept-Language
The Accept-Language request HTTP header indicates the natural language and locale that the client prefers. The server uses content negotiation to select one of the proposals and informs the client of the choice with the Content-Language response header. Browsers set required values for this header according to their active user interface language. Source
In Accept-Language client informs the server in what language wants to get a response.
Content-Language contains information about response culture.
The service is trying to convert the response into a given language in the Accept-Language header. However, there can be a situation where the server is not able to answer in a given language. In that case, the response can be in the default language. Information about the response language will be in the Content-Language header.
I have a number of services that require an X-Auth-Token header to be sent similar to the below:
X-Auth-Token: 2e5db4a3-c80f-4cfe-ad35-7e781928f7a2
I would like to be able to specify this in my API documentation following the API Blueprint standard. However, from what I can tell from the API Blueprint headers section definition, you can only specify literal values (e.g. Accept-Charset: utf-8) and not a schema for what the header should look like (e.g. something like X-Auth-Token (string)).
I get the impression that Traits might help with this problem but it's a little over my head at the moment. Can anyone tell me how to specify that all requests to a given action (or set of actions) require an X-Auth-Token header?
You are right about not being able to define a schema for headers. Unfortunately, API Blueprint doesn't support it yet.
Until something like that is supported, you can use the literal value for the header like the following:
+ Headers
X-Auth-Token: 2e5db4a3-c80f-4cfe-ad35-7e781928f7a2
API Blueprint also does not support any Traits currently. I am afraid you might have been confused by reading other feature requests.
According to this thread:
Custom HTTP headers : naming conventions
And the IETF link, using X- headers is no longer supported. However, I still see APIs that use them for responses. I've also recently done some configuration with nginx and it uses a few uses of X- headers. For example another post here:
Modifying a Location header with nginx proxy_pass
shows the use of X-Forwarded-For and a few others.
So.. via the IETF deprecation, is all use of any X- header basically being told to no longer use it? Or are their cases where it's allowed?
If they are no longer allowed, then do we return headers without the X- in it?
I ask because my REST API is returning login tokens (session tokens really) via x-auth-token: and consumers of my API would look for that header to get the token. I've seen many other APIs out there use a similar manner to provide oauth or other tokens.
I just want some sort of definitive understanding if x- is bad but we can still return custom headers without the x- (so in my case it would just be a response header named auth-token)?
Thanks.
I have seen the HTTP headers of Content-Language and Accept-Language, could someone explain what these are for and the difference between them? I have a multilingual site and wondering should I be setting both to the sites current selected language, by the user.
Content-Language, an entity header, is used to describe the language(s) intended for the audience, so that it allows a user to differentiate according to the users' own preferred language. Entity headers are used in both, HTTP requests and responses.1
Accept-Language, a request HTTP header, advertises which languages the client is able to understand, and which locale variant is preferred.2 There can be multiple languages, each with an optional weight or 'quality' value. For example:
Accept-Language: da, en-GB;q=0.8, en;q=0.7
(The default weight is 1, so this is equivalent to da;q=1, en-GB;q=0.8, en;q=0.7).
You're going to have to parse the values and weights to see if an appropriate translation is available, and provide the user the translation in the highest preferred language weight.
It is recommended you give the users an alternative, such as a cookie set value, to force a certain language for your site. This is because some users may want to see your site in a certain language, without changing their language acceptance preferences.
Content-Language is the language of the page you're serving.
Accept-Language is a list of languages you PREFER to accept.
Content-Language describes the language that a particular piece of content is intended for. Accept-Language is the list of languages that a user agent wants content in. The best way to think of this is that Content-Language describes content and Accept-Language conveys a preference.
The Content-Language entity-header field describes the natural language(s) of the intended audience for the enclosed entity. Note that this might not be equivalent to all the languages used within the entity-body.
The Accept-Language request-header field restricts the set of natural languages that are preferred as a response to the request
http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html
The Content-Language entity header is used to describe the language(s) intended for the audience, so that it allows a user to differentiate according to the users' own preferred language.
Header type Entity header
Forbidden header name no
CORS-safelisted response-header yes
CORS-safelisted request-header yes
— MDN Web Reference - HTTP Headers - Content-Language
The Accept-Language request HTTP header advertises which languages the client is able to understand, and which locale variant is preferred. (By languages, we mean natural languages, such as English, and not programming languages.)
Header type Request header
Forbidden header name no
CORS-safelisted request-header yes
— MDN Web Reference - HTTP Headers - Accept-Language
The Accept-Language request HTTP header indicates the natural language and locale that the client prefers. The server uses content negotiation to select one of the proposals and informs the client of the choice with the Content-Language response header. Browsers set required values for this header according to their active user interface language. Source
In Accept-Language client informs the server in what language wants to get a response.
Content-Language contains information about response culture.
The service is trying to convert the response into a given language in the Accept-Language header. However, there can be a situation where the server is not able to answer in a given language. In that case, the response can be in the default language. Information about the response language will be in the Content-Language header.