ContentDisposition

[seanmonstar]

The Content-Disposition header is a more complicated one, and coming up with an appropriate design that is easy and clear to use while also being efficient is important.

Where as most of the fields that can be set in CacheControl (#3) are known, and can be represented in bitflags, the fields of a ContentDisposition are typically strings. It'd be useful to be able to set these fields easily (not having to worry too much about converting to a valid HeaderValue), without needing to make several copies when parsing.

One option is to add a ContentDisposition::builder(), which can set the various fields, and the validity can be checked when build() is called.

[izderadicka]

Builder would be fine, in current situation header cannot be created for attachment, which is probably most common usecase for Content-Disposion.

[nox]

Is "make several copies" actually a problem now given that HeaderValue is backed by bytes::Bytes?

[ririsoft]

Builder would be fine, in current situation header cannot be created for attachment, which is probably most common usecase for Content-Disposion.

I am totally in line (pun not intended) with the proposal of having a builder interface. My use case is attachement/filename of course.

[xmakro]

What happened to the ContentDisposition struct that parses the filename? It seems to be commented out:

headers/src/common/content_disposition.rs

Line 113 in 1b4efe2

/*