Skip to content

Multipart: AHC shouldn't hardcode disposition-type as form-data #522

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
slandelle opened this issue Apr 3, 2014 · 0 comments
Closed

Multipart: AHC shouldn't hardcode disposition-type as form-data #522

slandelle opened this issue Apr 3, 2014 · 0 comments
Assignees
@slandelle
Labels
Enhancement
Milestone
1.8.5

Comments

@slandelle
Copy link
Contributor

form-data should only be a default value. Users should be able to force other values such as attachment. See http://www.w3.org/Protocols/rfc2616/rfc2616-sec19.html chapter 19.5.1.
slandelle pushed a commit that referenced this issue Apr 3, 2014
Make disposition-type configurable, close #522
8e10943
@slandelle slandelle added this to the 1.8.5 milestone Apr 3, 2014
@slandelle slandelle self-assigned this Apr 3, 2014
cs-workco pushed a commit to cs-workco/async-http-client that referenced this issue Apr 13, 2023
@dnadoba
Refactor redirect logic to be reusable for async/await (AsyncHttpClie…
c4feafd 
…nt#522)

* refactor RedirectHandler
- `redirectState` is no longer a property of `HTTPClient.Request`. RedirectHandler now stores this state directly and therefore no longer optional.
- we no longer count the number of allowed redirects down. Instead the number of redirects is dervied from `self.visited.count` and we compare it to the maxRedirect to check if we git the limit.

* `HTTPClient.Configuration.RedirectConfiguration.Configuration` is now called `HTTPClient.Configuration.RedirectConfiguration.Mode`
only two `Configuration`s left in the type name

* add redirect logger test
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@slandelle slandelle

Labels
Enhancement
Projects
None yet
Milestone
1.8.5
Development

No branches or pull requests
1 participant
@slandelle