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

Making an API GET request without the header Content-Type


Is it possible to make a HTTP GET request without the header Content-Type? Currently, I am trying to use google script to make an API call to TestRail API to retrieve data. I made a GET request to Testrail API, however the request return with error 400 (bad request) Header Content-Type is missing. Unfortunately, google script does not support the use of Content-Type in the header. Any workaround for this?

Content-Type header invalid, use Content-Type: application\/json

WORKAROUND: If you have access to the Apache configuration of your TestRail server, add the following directive:

# If an API call is coming in then add the Content-Type header
# (Fixes a bug with Google app scripts.)
<If "%{QUERY_STRING} =~ /api\x2Fv2/">
        RequestHeader set Content-Type application/json

Google app scripts strip out the Content-Type header from GET calls because it’s not required (since there’s no JSON payload in the request). So, the above directive will put that header back in for any request that includes /api/v2 in the URL query string.


Hi there!

Thanks for your posting. It seems that Google Script actually does support custom headers and this looks as follows:



In late 2015 or early 2016 Google made a change to UrlFetchApp.fetch() and the Content-Type header is not sent for any GET request, even if you put it in the request header. See Issue 6117: Content-Type header removed from UrlFetchApp.fetch() for more details. It doesn’t seem like they’re going to fix it either.


Ah okay, thanks Don. You workaround looks good for TestRail Server (self-hosted) installations and this should be a viable solution in this case.



Let me know when changes will be done for the testrail hosted installations? I am seeing the same error.


Hi Asok,

Thanks for your posting. The Content-Type header is currently required also for GET requests but we will look into making this optional with a future version. We recommend including the Content-Type for now.



Hi Tobias,
Unfortunately google UrlfetchApp is not supporting that. We are unable to import test cases into google sheets.

Do you have any work around for that?



Hi Asok,

There’s currently no workaround for that if your client doesn’t support this header. An alternative may be generate or download CSV files outside of Google Sheets and then just open the CSV files.



+1 for this change.

We are trying to integrate TestRail with the EazyBI plugin for JIRA and are currently unable to do so because the Content-Type header is required for the GET request.

EazyBI only supports a single header for authentication because they assume that the REST API won’t need additional headers for GET requests.

I saw the above-mentioned workaround, but unfortunately we are using IIS instead of Apache so we now have to try and figure out how to translate it and internet searches haven’t been very helpful.


Hi Chad,

Thanks for your feedback, that’s appreciated! Have you already seen the (native) JIRA integration provided by our JIRA add-ons?



Hey Tobias,

Yes, we already use the native JIRA support, but we need to be able to pull more specific data for the metrics we are trying to track. EazyBI meets those needs for issue tracking in JIRA so we would really like to be able to pull the TestRail data using the same tool, especially since EazyBI supports REST APIs.


Thanks for your feedback. Expecting multiple headers also for GET requests is quite common. Not necessarily Content-Type, but definitely Accept or similar to determine the response format. We decided on using Content-Type so we can use the same header for both GET and POST requests. I would be surprised if EazyBI supports HTTP requests but only a single request header. Have you already contacted the EazyBI support to see if they are able to help?



Hey Tobias,

But this is not as per the Spec. For the GET requests we don’t need to set the Content-Type. I don’t know why we are not considering fixing it? This is blocking our automation.



Hi Asok,

Thanks for your feedback! We will look into making the Content-Type header optional with a future version, however there’s no update on an ETA for this. We would recommend the workaround Tobias mentioned previously which would be to generate or download CSV files outside of Google Sheets and then just open the CSV files after they’ve been generated.



Are you aware that Content-Type specifies the media type of the request body (which only makes sense for a POST or PUT request). So why on Earth would you want a Content-Type header for GET requests? Or did you confound it with the desired media type of the response, which is specified by the Accept header?
In any case, your API is not standard compliant, and the fact that Chrome removes such a non-compliant Content-Type from a GET request makes your API completely unusable.

This means an integration project I have started will not be feasible, which means that Testrail will be much less useful to our team than we thought. I am very very angry.


Here is the rewrite mapping to use for IIS. Add this to a web.config file at the root of your testrail install:

            <rule name="Set Content Type of API Requests" patternSyntax="Wildcard">
                <match url="*" />
                    <add input="{QUERY_STRING}" pattern="/api/*" />
                    <set name="HTTP_CONTENT_TYPE" value="application/json" />
                <action type="None" />


Thanks for sharing this, Dan!



What is the current state on this? Is there an issue we can track to verify where this is at?

We too have a hard requirement to be able to use google appscript to access testrail (hosted cloud instance and thus no server work arounds). I too feel that if Testrail is claiming restAPI support then they should follow spec and not require a GET to specify content type.

This may likely cause us to use another solution other than Testrail as this is an important feature.


Completely agree. Reporting functionality and integration with our other tools is becoming of paramount importance with the way we work as a multi-team and multi-site organisation.

We are trying to collate automated test results (stored in TestRail) on a dashboard, and this content header issue is the latest TestRail hurdle we are encountering.

Guys - is the API due to be the subject of a major release / enhancement? It would make many users happy!