In my application, I use GET method to get a Excel file back. The url actually contains the parameters that server needs to generate the Excel file. However, sometimes, the parameters may become so long (more then 2000 characters).
I am considering using POST method, but it does not seem that POST method can return a document. Am I right?
Nop, how you request, say GET, PUT and POST, doesn't necessarily affect the server you response.
How to make the response depends on the program on server. If you want to send a binary file after a POST request is totally cool.
Just take a look at sites like megaupload, rapidshare, etc. All of them will send you a file after you POST the recaptcha code.
Related
According to : https://developers.docusign.com/docs/esign-rest-api/reference/envelopes/envelopedocuments/list/
The EnvelopeDocument model should have "sizeBytes" property on it.
However, I'm making calls to GET https://demo.docusign.net/restapi/v2.1/accounts/{{accountId}}/envelopes/{{envelopeId}/documents
and the payload does not have it.
I also tried hitting HEAD https://demo.docusign.net/restapi/v2.1/accounts/{{accountId}}/envelopes/{{envelopeId}/documents/{{documentId}
to see if I could read the headers without the actual content but that I receive a 404 NOT FOUND so it must not be supported.
The only way I can see to accomplish this would be to hit the download file endpoint directly, reading the content-length header, and then cancelling the request before streaming any data from it.
Is there a better way to do this?
The only way to do this would be to make a get envelope call
GET https://demo.docusign.net/restapi/v2.1/accounts/{{accountId}}/envelopes/{{envelopeId}/documents
Then in the headers, you will find Content-Length, this is the file size
Reached out to DocuSign and they confirmed there's no way to do this other than to hit the download endpoint and read the content length header.
After some experimentation i found this doesnt really work either because the Content Length header is not always accurate from their api. The only way I can see to do it is to download the entire file into memory and take a count of the bytes, or keep track of the byte count as you stream it to its destination.
I want to create a new tab and send data to it in a POST request from my chrome extension. I could use a GET request, but the data I am going to send could be arbitrarily long, and I want to JSON encode it(which also means I cannot use forms). I've only found two questions on SO about this, but both of them are talking about using a form, which is not desirable.
The reason I want to do this is because I want to request further input from the user before I do what I do with the data. I am totally lost here and have no idea how to do this, hence I can not add any code samples I've tried.
If I cannot do this with a URL, I could inject a script into the page and have a popup, but that is something of a last resort.
Any ideas on how this could be done?
I have a rest like API through Node Express.
The ETag is default, not explicitly turned on or off. However whenever I test hitting the server, it always gives me a new ETag, even if the returned JSON/HTML is exactly the same. I also checked the returned header and they look the same. I tested this with two types of content, an API and a static HTML content like a privacy page.
Any idea how to check what's making it different each time?
Express' default behavior is to provide a "strong"-ly validated etag which will only be the same as a previous response if the current response is precisely the same, byte-for-byte.
You could try setting express' etag to weally validate the response, which indicates to the browser that the current response is semantically equivalent as a previous one with the same value, that is, while they might not be byte-for-byte the same, they encapulate or represent the same meaning. To do this, use app.set('etag','weak')
Finally, if this doesn't work for you, you can create your own etag validation function using app.get('etag',function(body,encoding){...}) where you return a hash generated from your content; this allows you to control what express (and thus, the browser) considers being different means in the context of your response.
More than you ever wanted to know about etags can be found at Wikipedi:HTTP_ETag
The third-party libraries "node-formidable" and "express" come with the ability to handle multipart POST requests (e.g. with a file upload form), but I don't want to use any third-party code. How do I make the file upload process in pure JavaScript on Node.js?
There are very few resources in this regard. How can this be done? Thank you, love is.
Just to clarify because it seems some people are angry that the other answer didn't help much: There is no simple way of doing this without relying on a library doing it for you.
First, here's an answer to another question trying to clarify what happens on a POST file upload: https://stackoverflow.com/a/8660740/2071242
To summarize, to parse such an upload, you'll first need to check for a Content-Type header containing "multipart/form-data" and, if one exists, read the boundary attribute within the header.
After this, the content comes in multiple parts, each starting with the boundary string, including some additional headers and then the data itself after a blank line. The browser can select the boundary string pretty freely as long as such byte sequence doesn't exist in the uploaded data (see the spec at https://www.rfc-editor.org/rfc/rfc1867 for details). You can read in the data by registering a callback function for the request object's data event: request.on('data', callback);
For example, with boundary "QweRTy", an upload might look something like this:
POST /upload HTTP/1.1
(some standard HTTP headers)
Content-Type: multipart/form-data; boundary=QweRTy
--QweRTy
Content-Disposition: form-data; name="upload"; filename="my_file.txt"
Content-Type: text/plain
(The contents of the file)
--QweRTy--
Note how after the initial headers two dashes are added to the beginning of each boundary string and two dashes are added to the end of the last one.
Now, what makes this challenging is that you might need to read the incoming data (within the callback function mentioned above) in several chunks, and there are no guarantees that the boundary will be contained within one chunk. So you'll either need to buffer all the data (not necessarily a good idea) or implement a state machine parser that goes through the data byte by byte. This is actually exactly what the formidable library is doing.
So after having similar considerations, what I personally decided to do is to use the library. Re-implementing such a parser is pretty error-prone and in my opinion not worth the effort. But if you really want to avoid any libraries, checking the code of formidable might be a good start.
This is a bit old question, but still quite relevant.
I have been looking for a similar solution and no luck. So decided to do my own which might come handy to some other users.
GIST: https://gist.github.com/patrikbego/6b80c6cfaf4f4e6c119560e919409bb2
Nodejs itself recommends (as seen here) formidable, but I think that such a basic functionality should be provided by Nodejs out of the box.
I think you need to parse form by yourself if you don't want to use any modules very much. When uploading a file, the form will be in multipart/form-data format, which means your request content will be divided by a string that is generated randomly by your browser. You need to read this string at the beginning of the form, try to load data and find this string, then parse them one by one.
For more information about multipart/form-data you can refer http://www.w3.org/TR/html401/interact/forms.html#h-17.13.4.2
I think the best solution is to use formidable. It handles vary scenarios and works prefect I think.
I need to record how my client side scripts act in a 3rd party web app. So I am trying to use Fiddler to record the traffic on the 3rd party's machine and then run it here.
Sounds great, but my scripts make AJAX calls to an ASPX (123.aspx) page, and the calls use only POST params, not GET.
This means that the (123.aspx) request URLs recorded in Fiddler are identical, and playback doesn't work properly (every AJAX request matches the first recorded match, not the one with the same POST params).
E.g. let's says the requests are recorded like this
123.aspx [POST param: searchquery=xyz]
123.aspx [POST param: searchquery=abc]
then when I playback the SAZ file, I always get the response for 123.aspx [POST param: searchquery=xyz], even if searchquery=abc.
How can I get Fiddler to treat requests differently if the POST params are different?
I saw extraction rules, and was a little unsure about them, the Telerik documentation returns no results for 'extraction'... are they what I need?
Thanks
Please see the introductory blog post for details about Fiddler AutoResponder's Import for Playback mode which helps address some problems you may encounter when trying to playback a previously-captured SAZ file.
Now, the "Import for playback" mode will not address all possible problems; for instance, if you have multiple POSTs to the same URL captured but their ordering is not the same as was captured when you try to replay the scenario, they will play back in the wrong order and things will be broken.
From the Fiddler Book:
Matching Against Request Bodies
In some cases, a site may use the same request URL for many unrelated operations, specifying the operation desired in the request’s body instead of the URL. You may extend your Match Condition to examine a POST or PUT request’s body by specifying the URLWithBody: prefix for your Match Condition. When this prefix is used, the portion of the string up to the first space character is used as the Match Condition for the request’s URL, while the remainder of the string is used as a Match Condition for the string-representation of the request’s body. For performance reasons, you should specify the URL portion of the Match Condition as narrowly as possible to minimize the number of request bodies that the AutoResponder needs to evaluate. If a request has no body, it will not match any URLWithBody rule.
Your Match Condition may specify the EXACT:, NOT:, and REGEX: prefixes for both the URL and the body. For example:
URLWithBody:upload.php TextToFindInBody
URLWithBody:login.php EXACT:Action=Login
URLWithBody:ping.php NOT:POST Data I Do Not Care About
URLWithBody:EXACT:https://example.com/upload.php REGEX:^.+TextToFind.*$
URLWithBody:REGEX:^.+/upload.php.*$ REGEX:^.+TailOfPOST$
Keep in mind that most POSTs from Web Forms encode the body text, so you should ensure that your Match Condition accounts for such encoding. For instance, to match the following POST:
POST http://www.enhanceie.com/sandbox/FileForm.asp HTTP/1.1
Content-Type: application/x-www-form-urlencoded
Content-Length: 54
2=This+is+some+text&fileentry2=&_charset_=windows-1252
Your Match Condition should be:
URLWithBody:/sandbox/FileForm.asp This+is+some+text