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..