# HTTP "transfer coding" field.

## dE_logics

If you read RFC 2616 (HTTP 1.1), this field can either have value 'chunked' or 'transfer-extension' which boils down to -- 

transfer-extension      = token *( ";" parameter )

i.e. there'll be a token, and a ; separated parameter.

I understand what happens when it's value is 'chunked'; but other than this, no one wants to tell if it's value is token "*( ";" parameter )"

On searching for transfer-extension, all I get is RFCs.

I also read somewhere that this field is used for compression. Is that true? If so what's the advantage compared to transfer-encoding and content-coding method? And how exactly is it implemented?

----------

## tomk

The difference between content coding and transfer coding come down to whether is applies to the HTTP entity or the HTTP message. Generally transfer coding is only used for chunked messages, otherwise content coding is used. The transfer codings that are defined in HTTP 1.1 are "chunked", "identity", "gzip", "compress" and "deflate" AFAIK none of these use parameters. This site goes into more detail about the differences.

----------

## dE_logics

Ok, so if transfer coding field's value is not chunked, it's about the encoding of the body, whereas content-coding is about the entity/document/data to be transfered.

----------

