jmeter not able to accept parameters? - java

I have a weird problem.
I am not able to send request parameters to the LocalHost while uploading an image.
After selecting HTTP request sampler, I add request parameters, the add a file and parameter name for it. If I don't put parameter name for the image it accepts the request parameters, I put the parameter name for the image, then it doesn't accept the request parameters.
What could be the problem?
PS: I have HTTP cookie manager, HTTP request(for logging in and get the session), then another HTTP request for sending request parameters and image with the parameter name. At last View Results Tree.

The easiest way to format your request is to RECORD the action, and then modify the parameters. This guarantees several things:
You have the correct method (POST / GET / etc)
All parameter names are correct (the wrong character case can kill you)
All parameters are captured.
Additionally, JMETER has as field at the bottom of the HTTP request for attaching additional files. It is here that you need to specify the full file path and file type. This will most likely mirror what you've put into the parameters.

Related

Get the page that redirected you here, Spring MVC

I have the following problem. I want to use a controller, same for every page in my application. It is a common form included via include jsp in every page and it sends a mail to a predefined email account. The problem is, when I am posting the form, I get redirected to a blank page, with the url being my RequestMapping value despite the method called is actually void. So I need now to redirect me, after sending the mail to the page where I came from. How do I get access to the url link of the page that redirected me, into sending the email? Thanks
When returning void and one isn't handling writing the response yourself Spring MVC delegates detection of which view to render to a RequestToViewNameTranslator for which there is a single implementation the DefaultRequestToViewNameTranslator. Which basically takes the incoming URL, strips any suffixes (like .html etc.) and uses that as the viewname. The behavior you see now.
I guess you have 3 possible solutions
Add a hidden form attribute which contains the current page
Use the referer request header to determine where the request came from (not a 100% solution, See Alternative to "Referer" Header)
Submit the form through ajax so that you stay on the current page
For option 2 add the HttpServletRequest as a parameter to your request handling method and retrieve the header.
public String foo(HttpServletRequest request) {
String referer = request.getHeader("Referer");
return "redirect:" + referer;
}
I would probably go for option 3 and maybe add option 1 as a fallback when no javascript is available.

How can I better handle binary ReST resource errors when submitting a form to download those resources?

I have a service that generates a PDF document via a form of which GETs a ReST resource based on the input parameters. Some of these entries map to request path's and others map to optional request arguments such that the following illustrates the ReST resource.
/api/invoices/{invoiceNumber}?format={format}
On form submission I rewrite the action on the form to match the resource URI. But if the invoice number does not exist the resource will return 404 or any other error code required based on any error condition.
I can fix this instead by setting an error message on the page, but as the forms target is _blank to open a new window the form is redisplayed in the target window with the correct error message but of course the form is blank.
I would rather prefer the document was handled via an asynchronous ajax request that could detect and handle any error messages/conditions appropriately but I'm not sure if this is possible (with jQuery).
I don't think it's possible to conditionally open the window because you will have already downloaded the content into the parent window at that point. This may be possible using JQuery but typically sending content between windows is troublesome and fragile.
What I would do instead is on form submit
open a new window with an alternate action, e.g., fileShowAction, with your restful URL passed as a parameter
have the new window submit the URL via JQuery or as another form
if there's an error you can show an error with OK or timer to close the window
Option 2
Show the file in a JQuery inline dialog with an IFrame
Option 3
Have your initial REST call either return HTML with errors, etc., or a redirect to the file location. There are also several other alternatives using the semantics of REST e.g., using a Location header.

how to remove a header from URLConnection

I am talking to a file upload service that accepts post data, not form data. By default, java's HttpURLConnection sets the Content-Type header to application/x-www-form-urlencoded. this is obviously wrong if i'm posting pure data.
I (the client) don't know the content type. I don't want the Content-Type header set at all. the service has a feature where it will guess at the content type (based on the file name, reading some data from the file, etc).
How do I unset a header? There's no remove header, and setting it to null doesn't change the value and setting it to the empty string results in the header being set with no value.
I haven't tested this approach but you can try this:
Extend HttpURLConnection and try by overriding its getContentHandler() and setContentHandler(...) methods. Most probably this should work as, you will take a look at code of getContentHandler().
Use Apache HttpClient instead of URLConnection
Use fluent Request to generate your request
use removeHeader()
What do you mean "i don't want the Content-Type header to set at all"?
The browser (or other http client) sends your post request to the server, so it has to inform the server which way it encoded the parameters.
If the Content-Type header is not set, on the server side you (= your server) won't be able to understand how to parse the received data.
If you didn't set Content-Type, the default value will be used.
You browser (or other http client) MUST do two things:
Send key/value pairs.
Inform the server how the key/value pairs were encoded.
So, it is impossible to completely get rid of this header.
I just accomplished this by setting the header to null.
connection.setRequestProperty(MY_HEADER, null);

Refresh view after response

In one of my #RequestMapping POST methods I need to return HttpServletResponse (which is an xml file) and I want to refresh the view. Normally I would just return path but in this case it gets appended to the xml file which is being downloaded by user.
Is there any way to close and send response first and then generate(refresh) view?
I would say no, it's not. Not a 100 percent sure though. You could try to send the file and also set the redirect header in your response. I didn't try it just now but I guess you will just be redirected. Really depends on the browser though. A browser could decide to still download the file.
Once you sent the response a new request needs to be generated by the client, so there is no way to close it server-side and just create a new one.
I would suggest a solution using Javascript. Either AJAX or just setting the current location twice (first the download, then the new view). I'm not sure, I guess via location.href
Let me know if you need an actual code example, as it would take me some time to manufacture something.

Check if a URL's mimetype is not a web page

I want to check if a URL's mimetype is not a webpage. Can I do this in Java? I want to check if the file is a rar or mp3 or mp4 or mpeg or whatever, just not a webpage.
You can issue an HTTP HEAD request and check for Content-Type response headers. You can use the HttpURLConnection.setRequestMethod("HEAD") before you issue the request. Then issue the request with URLConnection.connect() and then use URLConnection.getContentType() which reads the HTTP headers.
The bonus of using a HEAD request is that the actual resource is never transmitted/generated. You can also use a GET request and inspect the resulting stream using URLConnection.guessContentTypeFromStream() which will inspect the actual bytes and try to guess what the stream represents. I think that it looks for magic numbers or other patterns in the stream.
There's nothing inherent in a URL which will tell you what you will receive when you request it. You have to actually request the resource, and then inspect the content-type header. At that point, it's still not clear what you should do - some content types will (almost) always be handled by the browser, e.g. text/html. Some types should be handled by a browser, e.g. application/xhtml+xml. Some types may be handled by the browser, e.g. application/pdf.
Which, if any, of these you consider to be "webpage" is still not clear - you'll need to decide for yourself.
You can inspect the content-type header once you're requested the resource, using, for example, the HttpURLConnection class.
content-type:text/html represents webpage.

Categories

Resources