search

hyperium / headers

Typed HTTP Headers from hyper
https://hyper.rs
MIT License
164 stars 83 forks source link

ContentDisposition #8

Open seanmonstar opened 6 years ago

seanmonstar commented 6 years ago

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 commented 5 years ago

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

nox commented 3 years ago

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

ririsoft commented 2 years ago

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 commented 7 months ago

What happened to the ContentDisposition struct that parses the filename? It seems to be commented out: https://github.com/hyperium/headers/blob/1b4efe2e9faac3d96ddfb9347c2028477663f01d/src/common/content_disposition.rs#L113