Issue with Content Type
Nobody has claimed this yet.
- Dominant language
- Ruby
- Stars
- 148
- Forks
- 95
- Avg merge
- 10h 54m
- Merged PRs (30d)
- 4
Description
We've identified an issue in the current release of net-http (0.3.2).
When setting a 'Content-Type' header on a POST request like so:
request['Content-Type'] = 'application/json'
It does set the header, however, it does not recognize that the Content-Type is set correctly and adds an additional header to the request with the default application/x-www-form-urlencoded
This can be seen when calling: request.to_hash.inspect:
{"accept-encoding"=>["gzip;q=1.0,deflate;q=0.6,identity;q=0.3"], "Accept"=>["*/*"], "User-Agent"=>["Ruby"], "Host"=>["api.songstats.com"], "Content-Type"=>["application/json"], "connection"=>["close"], "host"=>["api.songstats.com"], "content-length"=>["290"], "content-type"=>["application/x-www-form-urlencoded"]}
The only way to force the application/json header to go through is to explicitly set it in the request:
request.content_type = 'application/json'
So actually it needs to be set twice in order to fully work:
request['Content-Type'] = 'application/json'
request.content_type = 'application/json'
Also when setting request['content-type'] = 'application/json' in lower case it's throwing the error:
NoMethodError: undefined method `split' for nil:NilClass
from /Users/Oskar/.rbenv/versions/3.2.1/lib/ruby/3.2.0/net/http/header.rb:713:in `main_type'
It would be great if this can be streamlined so that setting the content-type in the headers immediately propagates across the entire request, without the need to set it multiple times or be cautious of case sensitivity. This took us a couple of hours to debug because we were un-aware that it currently sends the same header twice in the same request with different values.
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Reproduce the POST request and inspect request.to_hash, then read net/http/header.rb around line 713, where the reported lower-case Content-Type failure occurs. Trace how header assignment and content_type interact; done means case-insensitive header assignment produces one correct Content-Type without requiring a second setter.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- ruby
- Domain
- networking
- Issue type
- Bug
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 48/100