I am using below nodejs package to generate some simple restful APIs.
https://github.com/restify/node-restify
But I got a strange char at the end of the response json.
The server side code is the same as the above link provides.
How am I able to remove the %?
zsh adds a % sign to show that it was a partial line and no end-of-line delimiter was encountered. More here
CURL requests reply JSONs, without any EOL delimiter, hence % sign. Run the same command from bash shell and no such behaviour will be seen.
PS: Postman is really good tool to test APIs
Related
The problem is about getting a direct download link to a Netcloud file.
Documentation :
To obtain a direct link:
POST /ocs/v2.php/apps/dav/api/v1/direct
With the fileId in the body (so fileId=42 for example).
I want to POST this URL with Nodes.js. What is the XML (I guess) format to set "fileId=42" in the body of my request ?
Everything I try returns me
"Invalid query, please check the syntax. API specifications are here:http://www.freedesktop.org/wiki/Specifications/open-collaboration-services." but noway there to get the format.
Samething with curl, no syntax is working.
In a more generic way what is the XML (I guess) format when querying the OCS API?
I answer my question:
At last I suceeded in making it work with curl, single/double quotes in Windows was the problem, fixed using "{" escape character.
This told me this was not about OCS data format itself as data is to be sent as it, ie "fieldId=42"
Switching from NojesJs/https lib to Axios fixed the problem. Probably some content-type header, however I tried 'application/x-www-form-urlencoded' which fits with the data to send.
I am making a code in Python 3.7 for testing an application in Appium.
I am trying to send a text in an input field of an application. The text is in French with special characters (é, è, à, etc.).
My code managed to type character by character, one by one, but when it arrives to a special character with accent "é", it bugs! Here is error message:
Encountered internal error running command: io.appium.uiautomator2.common.exceptions.InvalidArgumentException: KeyCharacterMap.getEvents is unable to synthesize KeyEvent sequence out of '233' key code. Consider applying a patch to UiAutomator2 server code or try to synthesize the necessary key event(s) for it manually
I read the doc and forum and I added this capability:
desired_caps['unicodeKeyboard'] ='true'
But it didn't change anything. I still have same issue.
Try sending keys like:
self.driver.find_element().send_keys(u'éèà')
Change true to True
desired_caps['unicodeKeyboard'] ='True'
And this might help you
http://appium.io/docs/en/writing-running-appium/other/unicode/
"Received problem 3 in the chunky parser"
I can't for the life of me find what "problem 3" in curl refers to. I'm sure it has to do with the format of the chunk I'm sending from the app server to curl, but I can't figure out what is wrong with the chunk because I can't tell what "problem 3" is.
Any ideas?
The number you see there is CHUNKE_BAD_CHUNK from the CHUNKcode enum from lib/http_chunks.h from the libcurl source code. Given a quick look, it seems that it is mostly used when a CR or LF is missing from the chunked data.
I would recommend you investigate on the raw HTTP content stream to see what the problem is with the chunked format. RFC2616 section 3.6.1 documents it.
There is a similar post to yours. Again I'm not sure what your trying to sen across so I can not point out the problem but have look at this,
Why is this warning being shown: "Received problem 2 in the chunky parser"?
Hope this helps!
So, I ran into this with a CGI program.
Long story short, the CGI script was using Python, and printing the chunk header using the length of the string, then sending to the client using:
print data,
This appends a space, making the data one byte longer than the chunk header says it is. I fixed this by changing that line to:
stdout.write( data )
A hexdump of the data out of the CGI script was the tool that finally told me what was going on.
Here is the question.
Given the url http://www.example.com, can we read the first N bytes out of the page?
using wget, we can download the whole page.
using curl, there is -r, 0-499 specifies the first 500 bytes. Seems solve the problem.
You should also be aware that many HTTP/1.1 servers do not have this feature enabled, so that when you attempt to get a range, you'll instead get the whole document.
using urlib in python. similar question here, but according to Konstantin's comment, is that really true?
Last time I tried this technique it failed because it was actually impossible to read from the HTTP server only specified amount of data, i.e. you implicitly read all HTTP response and only then read first N bytes out of it. So at the end you ended up downloading the whole 1Gb malicious response.
So the problem is that how can we read the first N bytes from the HTTP server in practice?
Regards & Thanks
You can do it natively by the following curl command (no need to download the whole document). According to the curl man page:
RANGES
HTTP 1.1 introduced byte-ranges. Using this, a client can request to get only one or more subparts of a specified document. curl
supports this with the -r flag.
Get the first 100 bytes of a document:
curl -r 0-99 http://www.get.this/
Get the last 500 bytes of a document:
curl -r -500 http://www.get.this/
`curl` also supports simple ranges for FTP files as well.
Then you can only specify start and stop position.
Get the first 100 bytes of a document using FTP:
curl -r 0-99 ftp://www.get.this/README
It works for me even with a Java web app deployed to GigaSpaces.
curl <url> | head -c 499
or
curl <url> | dd bs=1 count=499
should do
Also there are simpler utils with perhaps borader availability like
netcat host 80 <<"HERE" | dd count=499 of=output.fragment
GET /urlpath/query?string=more&bloddy=stuff
HERE
Or
GET /urlpath/query?string=more&bloddy=stuff
You should also be aware that many
HTTP/1.1 servers do not have this
feature enabled, so that when you
attempt to get a range, you'll instead
get the whole document.
You will have to get the whole web anyways, so you can get the web with curl and pipe it to head, for example.
head
c, --bytes=[-]N
print the first N bytes of each file; with the leading '-', print all
but the last N bytes of each file
I came here looking for a way to time the server's processing time, which I thought I could measure by telling curl to stop downloading after 1 byte or something.
For me, the better solution turned out to be to do a HEAD request, since this usually lets the server process the request as normal but does not return any response body:
time curl --head <URL>
Make a socket connection. Read the bytes you want. Close, and you're done.
I am a couchDB newbie and am doing the examples in the O'Reilly CouchDB guide.
I have a problem using a view to retrieve a document by key:
curl http://127.0.0.1:5984/basic/_design/example/_view/by_date?key="2009/01/15 15:52:20"
gives the reply:
curl: (52) Empty reply from server
but just retrieving all rows:
curl http://127.0.0.1:5984/basic/_design/example/_view/by_date
gives me 3 rows including the specific row I am looking for:
{"id":"hello-world","key":"2009/01/15 15:52:20","value":"Hello World"}
why doesn't the key query work?
I am using CouchDB version 0.10.0 on Ubuntu 9.10
CouchDB expects the start_key parameter to be a valid JSON-compatible type, such as "a string" or 12345 or ["an", "array", "with", 5.0, "elements"]. If you check your CouchDB logs you will probably see a 400 (bad client request) entry because your key is either invalid UTF8 or invalid JSON.
You probably have two problems:
The shell is interpreting your quotes which must actually be sent to CouchDB. Try single-quoting your double-quote string.
You probably also need to encode your key so that it is a valid URL. Specifically, replace your space with %20
Putting this all together, the following works for me on CouchDB 0.11 on Ubuntu 9.10.
$ curl http://127.0.0.1:5984/blog/_design/docs/_view/by_date?key='"2009/01/30%2018:04:11"'
{"total_rows":1,"offset":0,"rows":[
{"id":"biking","key":"2009/01/30 18:04:11","value":"Biking"}
]}
It worked, I single-quoted the key string and encoded the space character so the request became:
/by_date?key='"2009/01/30%2015:52:20"'