http.ResponseWriter returns carriage return in body - http

I'm doing a coding exercise developing a HTTP server using Go's net/http library. The server is supposed to pass a series of tests in a Gitlab pipeline. I have no access to these tests and I can't see how they are implemented.
The problem is that one test for an expected HTTP 204 No Content response fails as follows:
Expected an empty response body "", got "\n"
The way I build the response in my code is:
// w is the http.ResponseWriter of the handler function.
w.WriteHeader(http.StatusNoContent)
w.Header().Del("Content-Type")
w.Write(nil)
I also tried w.Write(make([]byte, 0)) with the same result.
I'm testing it locally with curl but I can't really see the characters that are being returned in the body:
$ curl -i --header "Content-Type: application/x-www-form-urlencoded" --request POST --data "PARAMETER=1" host:9000/path
HTTP/1.1 204 No Content
Date: Thu, 10 Sep 2020 16:12:21 GMT
$
Is the net/http server actually returning a carriage return, and how can I prevent this?. Thank you.

Sorry, I was looking at the wrong piece of code. Because I don't have any details about the tests, I don't really know what exact case is being tested. The comments above are correct, just using w.WriteHeader(http.StatusNoContent) doesn't produce any carriage return in the body. No need to delete Content-Type. My mistake was that I was using http.Error(w, "", http.StatusNoContent) instead.

Related

httr replaces "%" with "%25" in URL sometimes

When using httr::GET, in certain queries it replaces % with safe representation %25, but in other queries it doesn't. I cannot find any rule that would make this happen.
I'm using httr 1.4.1
Sample query where % is replaced (notice the error code and that URL entered is not the same as in response object returned):
> httr::GET("jira.spring.io/rest/api/latest/search?jql=project=Spring%20Framework&startAt=0")
Response [https://jira.spring.io/rest/api/latest/search?jql=project=Spring%2520Framework&startAt=0]
Date: 2020-01-16 22:57
Status: 400
Content-Type: application/json;charset=UTF-8
Size: 196 B
Query where it is not replaced (no error, URL in response same as entered):
> httr::GET("issues.jenkins-ci.org/rest/api/latest/search?jql=project='WEBSITE'%20OR%20project='Infrastructure'&startAt=0")
Response [https://issues.jenkins-ci.org/rest/api/latest/search?jql=project='WEBSITE'%20OR%20project='Infrastructure'&startAt=0]
Date: 2020-01-16 23:02
Status: 200
Content-Type: application/json;charset=UTF-8
Size: 430 kB
What is going on? Is it a bug in httr? Or should I change some parameters in GET() call?
tldr; use HTTPS requests with jira.spring.io to avoid a broken protocol upgrade.
It's not an R/HTTR issue. It's the website. Compare the results of HTTP ("failing with mystery %25") and HTTPS ("succeeding"):
http://jira.spring.io/rest/api/latest/search?jql=project=Spring%20Framework&startAt=0
{"errorMessages":["Error in the JQL Query: The character '%' is a reserved JQL character. You must enclose it in a string or use the escape '\u0025' instead. (line 1, character 15)"],"errors":{}}
https://jira.spring.io/rest/api/latest/search?jql=project=Spring%20Framework&startAt=0
{"errorMessages":["Error in the JQL Query: Expecting either 'OR' or 'AND' but got 'Framework'. (line 1, character 16)"],"errors":{}}
There appears to be a 'malfunction' in the HTTP -> HTTPS redirect protocol upgrade, which has this response header:
Status Code: 301 Moved Permanently
Location: https://jira.spring.io/rest/api/latest/search?jql=project=Spring%252520Framework&startAt=0
^^^^^
Thus a solution is to use the HTTPS endpoint and avoid the strange target Location..

POST upload file works in curl but on Postman fails with error 415 or 500

I'm testing a simple Postman POST. I have an URL, POST; and I attach a file using "binary" under "Body" section. This is the only option (under Body) that allows me to simply browse a file and attach it to the request.
Without header:
415 Unsuported Media Type
When adding the header:
500
org.apache.commons.fileupload.FileUploadException: the request was rejected because no multipart boundary was found
In contrast, with curl, it works like a charm:
```bash
$ curl -sS -u llagos:*** -F "file=#i.png" -X POST http://osbdev/rest/api/2/issue/DVMG-1/attachments
What am I doing wrong; it's always me :(
Thanks a bunch!
Actually, you can also attach a file in form-data (in the KEY column you can choose File and then click on the Select Files in the VALUE column and attach it.
Regarding the multipart boundary, that question has been answered before, some interesting reading can be found here:
What is the boundary in multipart/form-data?

Using JSON in Header in Python Requests library

I want to make a request to an API which expects a JSON to be sent in the Header field. I'm unable to do it in Python Request library.
I'm able to do it in cURL.
cURL code:
curl -v -X POST https://content.dropboxapi.com/2/files/download
--header "Authorization: Bearer abcdefgh12343567"
--header "Dropbox-API-Arg: {\"path\": \"/folder/file.mp4\"}" -o file.mp4
Python code:
import requests
import simplejson
r = requests.post(
'https://content.dropboxapi.com/2/files/download',
headers={
'Authorization':'Bearer abcdefgh12343567',
'Dropbox-API-arg': simplejson.dumps({'path': '/folder/file.mp4'})
})
Here the Header contains a JSON string.
I'm trying to use Dropbox's files/download API documented here.
Even though the request is sent, the JSON value seems to be wrong.
The above code seems to work correctly now. I'm not sure about what happened - I was receiving HTTP 409 error earlier.
I was doubtful about how Python Requests Library would handle JSON string inside the header. So, I created an API to see how the server would read the headers made by both cURL and Python Requests. Both headers are identical.

CURL: can it have the data in the HTTP GET?

the following code snippet doesn't make sense to me.
curl -XGET 'localhost:9200/bank/_search?pretty' -H 'Content-Type: application/json' -d'
{
"query": { "match_phrase": { "address": "mill lane" } }
}
'
Does HTTP GET contain a body (data)?
No, GET takes only a QUERY_STRING, but no data.
Usually data are sent via POST or PUT HTTP verbs
Check http://www.restapitutorial.com/lessons/httpmethods.html
I found the answer here! In the ElasticSearch Docs.
https://www.elastic.co/guide/en/elasticsearch/guide/current/_empty_search.html
The HTTP libraries of certain languages (notably JavaScript) don’t allow GET requests to have a request body. In fact, some users are surprised that GET requests are ever allowed to have a body.
...

Microsoft cognitive API token doesn't work

I'm trying to use the Microsoft cognitive API for text analysis using the recommended curl method from their documentation:
curl -v -X POST "https://westus.api.cognitive.microsoft.com/text/analytics/v2.0/sentiment" -H "Content-Type: application/jscp-Apim-Subscription-Key: {bc94cba9b84748ebb2f2b79a28ee3450}" --data-ascii "{I had a wonderful experience! The rooms were wonderful and the staff were helpful.}"
But I get back:
{ "statusCode": 401, "message": "Access denied due to invalid subscription key. Make sure to provide a valid key for an active subscription." }
I also tried removing the {} surrounding token and text to be analyzed. What am I doing wrong here?
Note: yes I realize the security issue with showing key but I have re-generated thanks.
There are three issues with your request:
Content-Type header should be application/json. This is likely a copy-paste error.
Ocp-Apim-Subscription-Key header value must be the API without the curly braces. This is the cause for your 401 error.
The body must be JSON of a particular format. You can find the schema here.
Here's the rewritten request:
curl -v "https://westus.api.cognitive.microsoft.com/text/analytics/v2.0/sentiment" -H "Content-Type: application/json" -H "Ocp-Apim-Subscription-Key: $OXFORD_TEXT_KEY" --data-ascii '{"documents":[{"language":"en","id":"1234","text":"I had a wonderful experience! The rooms were wonderful and the staff were helpful."}]}'
Which should result in:
{"documents":[{"score":0.9750894,"id":"1234"}],"errors":[]}

Resources