curl: no matches found - api

trying to hit a public endpoint that works in the browser(gives json response), But does not in curl.
curl https://yts.lt/api/v2/list_movies.json?query_term=tt11296058
It gives the following message
no matches found: https://yts.lt/api/v2/list_movies.json?query_term=tt11296058
Not sure what could be the issue here, any input would be appreciated.

It may be due to do with what shell you are using. Try wrapping the URL in single or double quotes as suggested here.
Here is the quote from the above link discussing ZSH.
You need to escape the question mark, otherwise zsh thinks it is a globbing or wildcard character and tries to find files that match it (that's why it says no matches found).

Related

How can I pass string param containing slash character in postman?

I have a scenario where I have to pass
https://domain/sample?sysparm_query=abc/def&sysparm_display_value=true
in postman. However I am not getting the desired answer. I even tried encoding / with %2F, but does not work.
I don't see any problems with that character.

How to handle (REAL) blank space in Apache?

I know there are many questions like that in stackoverflow. But it is actually different :)
My problem is that Apache (2.4.6) just cannot handle white spaces in a url for instance aspecially used by cURL. Well consider I have a URL like following:
http://10.0.0.1:1234/Some Service/Root?func=getMessage
IF I browse this URL in any popular browser, they change the white space (' ') to %20. And in that way Apache can handle the request (or wget also does so).
However, when I use cURL, it does not change to %20 and in that case Apache return Error 400. I think the reason is, in the end of the GET Url, there is a white space and then specifies the used HTTP protocol comes.
such as:
GET Some Service/Root?func=getMessage HTTP1.1
The problem is I cannot touch or perform any update on cURL site. For example, I cannot perform a sed operation before cURL request. So consider like cURL site is like a blackbox. I have no control on that site. Therefore, I really have to solve this problem only in Apache. Unfortunately, It is the only option for me.
RewriteRules that I found work with if URL contains %20 instead of real white space (' '). For example \s only for if I write down %20 in the curl request. For example:
curl -v "http://10.0.0.1:1234/Some%20Service/Root?func=getMessage"
But if I use like:
curl -v "http://10.0.0.1:1234/Some Service/Root?func=getMessage"
then it gets Erro 400 because of the space.
For example following solution for %20 exists if there is one space or more then one:
#executes repeatedly as long as there are more than 1 spaces in URI
RewriteRule "^(\S*)\s+(\S* .*)$" $1+$2 [N,NE]
#executes when there is exactly 1 space in URI
RewriteRule "^(\S*)\s(\S*)$" /$1+$2 [L,R=302,NE]
So my link may not as simple as following:
http://10.0.0.1:1234/Some Service/Root?func=getMessage
Probably it may include one space :) but there will be more than one parameters like
http://10.0.0.1:1234/Some Service/Root?func=doSomething&id=123&pid=123&message=blabla&name=john&surname=doe
But in any case, ofcourse, I need also prevent possible problems if there is more then one blank.
Thanks in advance
It seems that Nginx can handle blanks or white spaces. Nginx does not give 400.

Is there a special case in Apache2 when calling a CGI and the URI includes a single query string parameter without a value?

Today I got an error and was very surprised to get it since everything looked just fine...
I have a CGI written in C++ which accepts URIs with a query string. The query string is what selects the page, etc. The CGI is installed in the standard location for an Ubuntu installation:
/usr/lib/cgi-bin/snapmanager.cgi
Today I was finishing up adding a Login screen and once logged in, I wanted to add a logout link. The link simply adds ?logout at the end of the URI:
http://www.example.com/cgi-bin/snapmanager.cgi?logout
That failed.
Checking the error log, I got an error saying that "logout" actually appeared on the command line. Rather surprising, if you ask me! I tried with:
http://www.example.com/cgi-bin/snapmanager.cgi?logout=now
and everything worked as expected. No logout on the command line.
I also tried:
http://www.example.com/cgi-bin/snapmanager.cgi?logout&host=foo
And that worked too. Again, no logout on the command line.
However, if I switch the parameters position it fails again:
http://www.example.com/cgi-bin/snapmanager.cgi?host=foo&logout
So it looks like Apache2 calls my CGI with the logout query string as a parameter on the command line when that one query string name is defined last.
Just in case, I tried to add dashes at the start of the name, and sure enough, that appears as a command line switch in my logs!
error:snapmanager.cgi: option --logout is not supported.
Really scary. This is a huge security risk if you know of a switch that can "tweak things your way"...
Is that documented somewhere?
I actually found the answer in RFC3875 in paragraph 4.4
4.4. The Script Command Line
Some systems support a method for supplying an array of strings to the CGI script. This is only used in the case of an 'indexed' HTTP query, which is identified by a 'GET' or 'HEAD' request with a URI query string that does not contain any unencoded "=" characters. For such a request, the server SHOULD treat the query-string as a search-string and parse it into words, using the rules
search-string = search-word *( "+" search-word )
search-word = 1*schar
schar = unreserved | escaped | xreserved
xreserved = ";" | "/" | "?" | ":" | "#" | "&" | "=" | "," |
"$"
After parsing, each search-word is URL-decoded, optionally encoded in a system-defined manner and then added to the command line argument list.
If the server cannot create any part of the argument list, then the server MUST NOT generate any command line information. For example, the number of arguments may be greater than operating system or server limits, or one of the words may not be representable as an argument.
The script SHOULD check to see if the QUERY_STRING value contains an unencoded "=" character, and SHOULD NOT use the command line arguments if it does.
Emphasis Mine

400 Bad Request when URL ends with %

All the URLs ending with % is giving following error
"Bad Request,Your browser sent a request that this server could not understand."
I have redesigned my website and earlier as per my google analytics URLs ending with % was running.
I want to mention that I tried using same old htaccess but was not able to fix it. Other important change which I made was in hosting where I have pointed my server into a sub folder or the root.
Please help me in fixing it
% is a reserved character and should not be used for anything except percent encoding.
If you really need to pass the character on your url, use %25
Try this: 400 Bad Request when URL ends with %
(move your mouse over it and look at the URL, it's the URL of this page with a % added to it!)
The problem is probably that the % is used as an escape character for special signs like spaces or non latin characters, and the browser expects a code behind it.

CLPlacemark.subThoroughfare strange characters?

When logging out or sending (to a web service using RestKit) specifically the subThoroughfare property of CLPlacemark strange characters appear where I would expect a hyphen to be.
Logging:
NSLog(#"%#", placemark.subThoroughfare);
Results in:
12-
Where I would expect 12-15. The 15 is missing.
Also, when sending the subThoroughfare string to a JSON service I see the following in the request:
12â??15
The 15 is present, however the hyphen is replaced by strange characters.
Have not been able to find a solution via Google/SO, and any help would be appreciated.
Edit:
A fuller example of an address logged to the console is:
Placemark Address: 34–36 Friars Way, Eaton, Engla
Note the last 2 characters are also missing (should read 'England'), when the – replaces the hyphen (-). I am looking into encoding, however not getting far.
Turns out that the strange characters are due to the LLDB debugger not being able to show Unicode characters correctly...switching to GDB showed the characters correctly.