I have a Jetty.Server.Request object, which is an HTTP request whose body I need to use in multiple methods.
I access the body's contents like so -
String contents = baseRequest.getReader().readLine();
However, this seems to remove the body from the HTTP request. If I then try to access it again like so -
String contents2 = baseRequest.getReader().readLine();
contents2 will be null.
How can I read the body of the request object without affecting the request?
Per the Servlet spec, the stream is only available once.
Make a copy of it yourself (either to memory, or to disk for later reading)
This is by design, as many request bodies can by quite large and there simply wouldn't be enough memory to handle rereads in a sane way.
Be sure you check out the prior answers for this:
Http Servlet request lose params from POST body after read it once
As those answer demonstrate a few ways to accomplish multiple reads of the same request body.
Related
I have come across the https://jxbrowser.support.teamdev.com/support/solutions/articles/9000013108-network-events in the JXBrowser and wanted to add new cookies so that it could be used in the subsequent calls.
The support is available to add headers however since no direct access is available for the cookies I tried using the
public void onBeforeSendHeaders(BeforeSendHeadersParams paramBeforeSendHeadersParams)
{
List<Cookie> cookieList = browser.getCookieStorage().getAllCookies();
}
Also note that the calls of below snippet produces the same exception
browser.getURL(); //Exception is thrown here
CookieStorage storage = setCookies(paramBeforeSendHeadersParams, browser, list);
storage.save();// Exceptino is thrown here
but if i do this i get
java.lang.IllegalStateException: You are trying to execute some code that invokes synchronous message send to IPC channel. This code is executed in the scope of the handler which is bounded to synchronous message received from IPC channel. Such code execution causes a deadlock in native code with high probability and is forbidden.
What is the reasoning behind this any help is appreciated
As I understand, you want your application to share cookies between several Browser instances.
It is possible to make Two Browser instances with the same BrowserContext instances which use the same user data directory. As a result, they will share cookies and cache files. For example:
BrowserContext context = new BrowserContext(
new BrowserContextParams("C:\\my-data1"));
Browser browser1 = new Browser(context);
Browser browser2 = new Browser(context);
In this case, you should not receive the exception.
MockWebServer is awesome library, but there is one thing that is surprisingly hard to do: set default response.
To be specific: I want to have ability to set response that is returned if no response was specified using server.enqueue(response).
I would like to be able to do something like:
server.setDefaultResponse(okResponse)
server.enqueue(customResponse)
And then when my tests call server twice (or more), every response after the first one would be okResponse.
When tests get more complicated and multiple calls to server are needed, sometimes specifying every single response (often simple 200 OK) is tedious and pollutes tests.
Is there any simpler way to do this than creating your own Dispatcher? Creating it properly (with support for multiple responses) sounds like overkill for such a small thing.
There is improvement that can be done in comparison to implementing your own Dispatcher. When looking at MockWebServer implementation I found that its default dispatcher is QueueDispatcher.
And it has some very handy methods, like:
public void setFailFast(boolean failFast)
public void setFailFast(MockResponse failFastResponse)
setFailFast(true) sets server to "fail fast" mode i.e. if no response in enqueued, it doesn't wait, just returns HTTP 404 response immediately.
setFailFast(okResponse) sets response to return in "fail fast" mode, which exactly answers this question.
The problem is, you don't have direct access to dispatcher field in MockWebServer, so what you need to do is set your own instance of QueueDispatcher and then set default response (or "fail fast" response) on it, like that:
val dispatcher = QueueDispatcher()
dispatcher.setFailFast(okResponse)
server.setDispatcher(dispatcher)
rest API:
someting/post expects 'token' as bytearray body data
something/delete expects 'token' as bytearray body data
Using Qt I can prepare the data in a QByteArray and send via deleteResource (that doesn't accepts a data parameter) and I can use sendCustomRequest that accepts a data parameter, but if I use the later with DELETE I have no data.
With POST, I do have the data.
Minimal code example, python server - just to exemplify. the Qt code is below.:
#route('/something/delete', "DELETE")
def somethingDelete(url, post):
print(post) # empty
#route('/something/delete2', "POST")
def somethingDelete2(url, post):
print(post) # correct output.
and the Qt code that triggers the server calls - This code is higly shortened to simplify, but the idea is that.
QNetworkRequest req;
req.setRawHeader("OCS-APIREQUEST", "true");
req.setUrl = Utility::concatUrlPath(account()->url(), path());
QByteArray bufferData("token=" + _token);
sendCustomRequest(req, "POST", bufferData);
as soon as I change the POST to DELETE, I don't get the token, but the correct python function is executed.
The DELETE HTTP verb does not have a request body so your buffer is probably simply dropped by Qt. To use DELETE you would need to encode your token in the URL.
As of Qt 5.9.2, it seems that Qt might ignore body data when performing a DELETE operation.
In Qt code in QNetworkReplyHttpImplPrivate::postRequest(), one can see that createUploadByteDevice() is not called when the operation is QNetworkAccessManager::DeleteOperation.
However, this is only valid when the DELETE request is sent by calling QNetworkAccessManager::deleteResource(), which is the only way to create a network request with the QNetworkAccessManager::DeleteOperation operation. Also note that this function does not allow you to send any body data.
If you use QNetworkAccessManager::sendCustomRequest() to send the request, then as far as Qt is concerned the operation is QNetworkAccessManager::CustomOperation. The custom verb you pass is not processed further, and Qt will behave exactly the same whatever the value of verb is. Even if verb is a known value like POST or DELETE.
This means that Qt does not discard the body data.
So if you used QNetworkAccessManager::sendCustomRequest(), as you claim, your body data is sent to the server (confirmed by Wireshark). So the issue is not on Qt side, but on the server side.
I'm trying to write some tooling for Crystal (specifically Kemal) where I can see if the response content type is text/html and modify the response body thats has already been written to the HTTP::Response before it is sent to the client by injecting an HTML element into the existing html response body.
I've noticed that HTTP::Server::Response is write-only, but things like Gzip::Writer are able to modify the body.
How can I modify the HTTP::Server::Response html body before it is sent to the client?
It's written in Crystal, so let's just take a look at the source on how others do this.
Taking the CompressHandler as an example, the basic idea is to replace the response's IO with something that allows the desired control:
context.response.output = Gzip::Writer.new(context.response.output, sync_close: true)
# ...
call_next(context)
So how can we make use of that to modify the response that's being written?
A naive (and slow) example would be to just keep hold of the original output and provide a IO::Memory instead:
client = context.response.output
io = IO::Memory.new
context.response.output = io
call_next(context)
body = io.to_s
new_body = inject_html(body)
client.print new_body
Of course that would only work when this handler comes before any handler that turns the response into non-plaintext (like the above CompressHandler).
A smarter solution would provide a custom IO implementation that just wraps the original IO, watching what's written to it and inject whatever it wants to inject at the right point. Examples of such wrapping IOs can be found at IO::Delimited, IO::Sized and IO::MultieWriter among others, the pattern is really common to prevent unnecessary allocations.
I am working with one soap request where we need to pass,single data in one parameter and in 2nd iteration we need to pass multiple test data in same input request.Please help me how to change input soap request as per test data,please find below soap requests for single and multiple requests.
Single Request:
<ReqDtls>
<vReqs>
<amount>1.00</amount>
<cardNo>8897654778999</cardNo>
</Reqs>
<cardType>caredit</cardType>
</ReqDtls>
Multiple Requests:In same soap input requests,it is changing dynamically from POS system but i want to perform in loadrunner.
<ReqDtls>
<vReqs>
<amount>1.00</amount>
<cardNo>8897654778999</cardNo>
</Reqs>
<vReqs>
<amount>2.00</amount>
<cardNo>890897654778999</cardNo>
</Reqs>
<cardType>caredit</cardType>
</ReqDtls>
Any code in vugen to pass this type of values from excel file for loadtesting,please help how to do this one
This is where you will use your foundation skills in programming as well as a web_custom_request() (Potentially) to send your own custom string.
Notice the repeated piece here
<vReqs>
<amount>{amount_variable}</amount>
<cardNo>{card_variable}</cardNo>
</Reqs>
You have a defined header
<ReqDtls>
And a defined footer
<cardType>caredit</cardType>
</ReqDtls>
This now becomes a matter of string concatenation in C and turning the variables into literals. Consider a loop and lowly sprintf() for this task. Note, variable declarations are not included in the code fragment
sprintf(mybigstring,"<ReqDtls>\r");
for (myloopcounter=1;myloopcounter<=mylooplimit;myloopcounter++)
{
sprintf(mybigstring,
"%s%s",
mybigstring,
lr_eval_string("<vReqs>\r<amount>{amount_variable}</amount>\r<cardNo>{card_variable}</cardNo>\r</Reqs>\r") );
lr_advance_param("amount_variable");
lr_advance_param("card_variable");
}
sprintf(mybigstring,"%s%s",mybigstring,"<cardType>caredit</cardType>\r</ReqDtls>");
The above is directly from noggin to screen so it may require a bit if fiddling, but it should give you an idea for a path.
Once you have your string, then you can use it in whatever request as needed.