What is the difference between HTTP parameters and HTTP headers?

Question

I read this question but it didn't answer my question.

To me Headers and Parameters are both dictionaries with the difference that headers is [String : String] while Parameters is [String : AnyObject]? and so if your parameters are also Strings then you could send them within the headers (while using a 'x-' prefix to signify they aren't standard headers) which is a common but not good practice.

• Is that correct?
• Are there other difference between headers and parameters?
• What kind of other non-String types would you be sending using parameters?

Alamofire Request method

public func request(
        method: Method,
        _ URLString: URLStringConvertible,
          parameters: [String: AnyObject]? = nil,
          encoding: ParameterEncoding = .URL,
          headers: [String: String]? = nil)
        -> Request
    {
        return Manager.sharedInstance.request(
            method,
            URLString,
            parameters: parameters,
            encoding: encoding,
            headers: headers
        )
    }

As an example I have seen people passing ["x-ios-version" : UIDevice.currentDevice().systemVersion] or build versions through headers

Barbarity

The HTTP spec says "The request-header fields allow the client to pass additional information about the request, and about the client itself, to the server." The headers are for meta information about the request that allow the web server to parse the request. On the other hand, the parameters of a request are the actual content of the request. I wouldn't conflate the two just because they both happen to consist of pairs of keys and values. – Crashaw

@Crashaw OK. I'm asking what I should do. ALSO I'm asking what others do :) regardless of it being good...So I can understand there code and how other use HTTP headers. So sorry if I'm repeating myself: if your parameters are also Strings then you could send them within the headers (while using a 'x-' prefix to signify they aren't standard headers) which is a somewhat common but not good practice <-- do some use it this way? – Barbarity

I really don't understand. You're asking whether you can add your own custom headers with information that really belong in the parameters, even though you know that's not good practice? Sure, but that's a bad idea. If you have an example of a parameter that you're contemplating making a header, please edit the question to include that. – Crashaw

That's a good example of something that legitimately could be a header. – Crashaw

@Crashaw :/ I don't get it! I was expecting you to say it's bad. By what criterion it shouldn't be in parameters? Or it's just a preference and so you won't have to send 2 objects? – Barbarity

Let us continue this discussion in chat. – Crashaw

Answer 1

Here is the list of differences:

1. They are designed for different purposes. Headers carry meta info, parameters carry actual data.

2. HTTP Servers will automatically un-escape/decode parameter names/values. This does not apply to header names/values.

3. Header names/values need to be manually escaped/encoded at client side and be manually un-escaped/decoded at server side. Base64 encoding or percent escape is often used.

4. Parameters can be seen by end-users (in URL), but headers are hidden to end-users.

Coombs

So if I wanted to send something in Arabic, I had to use parameters? – Barbarity

Yes unless you convert the Arabic text to Base64 text - for example. – Coombs

Or percent escape it. But whatever you do, you have to manually reverse the process on the server end (where as parameters are generally automatically interpreted by web servers based upon the Content-Type header of the request). – Crashaw

Answer 2

The accepted answer is very practical. Make sure you see it. But there are two foundational differences I will discuss in depth:

Where header and parameters are placed in an HTTP Request

A URL is different from an HTTP Message. An HTTP Message can either be a Request or a Response. In this answer I will focus on the request. An HTTP Message is just a String with a very specific structure/standard.

An HTTP Request is made up of mainly the url, http-method, http-headers (there are other chunks in it, but I'm just mentioning the ones we care about the most)

Request       = Request-Line              ; Section 5.1
                *(( general-header        ; Section 4.5
                  | request-header         ; Section 5.3
                  | entity-header ) CRLF)  ; Section 7.1
                CRLF
                [ message-body ]          ; Section 4.3

A request line is:

Request-Line   = Method SP Request-URI SP HTTP-Version CRLF

CLRF is something like a new line.

For more see here and here. You might have to do some back and forth between the links til you get it right. If you really wanted to go deep then see see this RFC

So basically a request is something like:

POST /cgi-bin/process.cgi?tag=networking&order=newest HTTP/1.1
User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)
Host: www.tutorialspoint.com
Content-Type: text/xml; charset=utf-8
Content-Length: 60
Accept-Language: en-us
Accept-Encoding: gzip, deflate
Connection: Keep-Alive

first=Zara&last=Ali

The query params are within the URL. HTTP Headers are NOT part of the URL. They're part of the HTTP Message. In the above example, query params is tag=networking&order=newest, the headers are:

User-Agent: Mozilla/4.0 (compatible; MSIE5.01; Windows NT)
Host: www.tutorialspoint.com
Content-Type: text/xml; charset=utf-8
Content-Length: 60
Accept-Language: en-us
Accept-Encoding: gzip, deflate
Connection: Keep-Alive

So when you make a network request, you're sending a structured STRING using the http protocol. That string is sent through a TCP connection.

2 - Why and where one is preferred over the other

From discussion with Rob in chat:

The criteria is that if it's information about the request or about the client, then the header is appropriate.
But if it's the content of the request itself (e.g. what you are requesting from the server, some details that identify the item to be returned, some details to be saved on the web server, etc.), then it's a parameter e.g.:

Parameter
Let's say you're requesting an image for a product. The product id may be one parameter. The image size (thumbnail vs full size) might be another parameter. The product id and requested image size are examples of "some detail" (or parameter) being supplied as part of the content of a request.

Header
But things like the request is JSON or x-www-form-urlencoded are not the content of the request, but meta data about the request (especially since it's necessary for web service to know how to parse the body of the request). That's why it's a header.

Most likely if your app makes various requests, its headers would have a lot in common. However the parameters due to the fact that they are content based should be more varied.

---

Construction using URLComponents

class UnsplashRequester {
    
    static let session = URLSession.shared
    static let host = "api.unsplash.com"
    static let photosPath = "/photos"
    static let accessKey = "My_access_key"
    
    static func imageRequester(pageValue: String, completion: @escaping (Data?) -> Void) {
        var components = URLComponents()
        components.scheme = "https"
        components.host = host
        components.path = photosPath

        // A: Adding a Query Parameter to a URL
        components.queryItems = [URLQueryItem(name: "page", value: pageValue)]
        let headers: [String: String] = ["Authorization": "Client-ID \(accessKey)"]
        
        var request = URLRequest(url: components.url!)
        for header in headers {
            
            // B: Adding a Header to a URL
            request.addValue(header.value, forHTTPHeaderField: header.key)
        }
        
        let task = session.dataTask(with: request) { data, _, error in
        }
    }
}

Barbarity