Subscribe Join 180,000+ subscribers and receive articles from our blog about software quality, testing, QA and security. Subscribe

Making an API GET request without the header Content-Type

Google just updated the bug I opened with them saying that their app script code will no longer remove the Content-Type header in GET requests using their UrlFetchApp call.

So app script API calls to TestRail instances that haven’t been configured to work around this issue (like the hosted TestRail instances) should now work.

Any update on this, it makes non sens to send a content-type header for a GET request which is by definition without content.
@tgurock Why don’t you simply update your API? It will ease a lot the life of our client and will take only few minutes on your side to fix it.

Again, another instance of this causing a halt to a BIG integration project.

Integration using OLE through MSXML2.XMLHTTP. Works find on a Window7 Enterprise laptop, sending the illogical “Content-Type” header.

Header seems to be stripped out from Windows 10 machine.

NOT running in Google, etc, Running within Rational DOORS.

Exporting/Importing CSV files is NOT an option

Hi All,

Thank you for the feedback! We do still have plans to review making the Content-Type header optional for API GET requests and I’ve added these new votes. Unfortunately, we are unable to provide a timeframe for this yet.

Regards,
John

Thx for your answer. It’s really sad to see that such small improvement (must be really quick to do), take so many time.

Signed up an account to post this issue. GET requests are not supposed to include a Content-Type, so requiring that we break the HTTP spec (something many clients will not allow, e.g. the .NET Core HttpClient) is a pretty awful design. Please fix this asap!

Bumping again. This issue is so dumb. It makes it such an incredible pain to use the API with any kind of HTTP framework that attempts to enforce the standard.

Please fix this! You are asking us to break the HTTP standard! Content-Type is not a valid header for HTTP GET Requests.

@cow_trix

Hey Sean,

We can’t provide any specific timeline for when that feature will be available, but for now I’ve added your feedback to this highly requested feature to help the development team in planning for upcoming releases.

Regards,
Shanu

@shanu.mandot @tgurock

Just made an account to comment on this as well.
This issue is not documented anywhere except this random thread, and as noted above, breaks the standard in an unexpected way making interoperability impossible. I lost some hours of work today due to this, which unexpectedly ruins a project I had planned.

Please fix this! It has been 4 years!

@pseudonymous

Hey,

Welcome to the TestRail Community and thanks for your feedback.

Regards,
Shanu

Please note that this also makes it impossible to make these GET requests via a browser, a common method of testing. I don’t really see how this change could be a significant amount of work, surely it’s just removing the check which forces us to violate the HTTP standard? A bit frustrating to be paying a license and not see a few hours work to fix a pretty large issue with interoperability. This is significant enough an issue to deserve its own patch IMO. Gurock is making it functionally impossible to write any service that interacts with the TestRail API that uses an HTTP layer which enforces this part of the standard, which is a fair proportion of them.