Is it appropriate or necessary to use percent-encoding with HTTP Headers?

Question

When I'm building RESTful client and servers, is it appropriate or necessary to use percent-encoding with HTTP Headers (request or response), or does this type of encoding just apply to URIs?

Take a look yourself, RFC 2616 is the most important definition for the http protocol: http://tools.ietf.org/html/rfc2616 — arkascha, Apr 22 '14 at 09:20
Possible duplicate of [HTTP header should use what character encoding?](http://stackoverflow.com/questions/4400678) — lefloh, Apr 22 '14 at 12:36
possible duplicate of [HTTP header should use what character encoding?](http://stackoverflow.com/questions/4400678/http-header-should-use-what-character-encoding) — Pedro Werneck, Apr 22 '14 at 19:43

score 13 · Accepted Answer · edited Nov 09 '21 at 15:25

Basically No, but see below.

RFC2616 describes percent-encoding only for URIs (search for % or HEX HEX or percent) and it defines the field-value without mentioning percent-encoding.

However, RFC2616 allows arbitraty octets (except CTLs) in the header field value, and has a half-baked statement mentioning MIME encoding (RFC2047) for characters not in ISO-8859-1 (see definition of TEXT in its Section 2.2). I called that statement "half-baked" because it does not exlictly state that ISO-8859-1 is the mandatory character set to be used for interpreting the octets, but despite of that, it normatively requires the use of MIME encoding for characters outside of that character set. It seems that both the use of ISO-8859-1 and the MIME encoding of header field values are not widely supported.

HTTPbis seems to have given up on this, and goes back to US-ASCII for header field values. See this answer for details.

My reading of this is:

For standard header fields (those defined in RFC2616), percent-encoding is not permitted.
For extension header fields, percent-encoding is not described in RFC2616, but there is room for applying all kinds of encodings, including percent-encoding, as long as the resulting characters are US-ASCII (if you want to be future-proof). Just don't think you have to use percent-encoding.

Some more sources I found:

https://www.quora.com/Do-HTTP-headers-need-to-be-encoded confirms my understanding, although it is not specific about standard headers vs extension headers and does not quote a source.
https://support.ca.com/us/knowledge-base-articles.TEC1904612.html argues that the percent-encoding of extension headers in their product is a measure of protection against CSS attacks.

Marking this as the accepted answer for now since it fairly concisely answers the question. — Andrew Ferrier, Jan 02 '18 at 10:01

score 0 · Answer 2 · edited Oct 07 '21 at 12:12

0

TL;DR: Octet percent-encoding and base64 encoding are fine.

Indicating Character Encoding and Language for HTTP Header Field Parameters https://www.rfc-editor.org/rfc/rfc8187

This document specifies an encoding suitable for use in HTTP header fields...

Read the "3.2.3. Examples"

base64 encoding is fine too, as read the HTTP Basic Authorziation spec: https://www.rfc-editor.org/rfc/rfc7617

edited Oct 07 '21 at 12:12

Community

1
1

answered Nov 27 '20 at 11:32

István Pató

351
3
7

Note that all of this only applies to header fields that specifically allow these kind of escape mechanisms. – Julian Reschke Nov 27 '20 at 12:43

Is it appropriate or necessary to use percent-encoding with HTTP Headers?

2 Answers2