System I have to update has http-handlers that are accessible via address like
http://<server>/handlers?name=some-handler-name
I added http form with action tag that directs to one of this handlers like this:
<form ... action="/handlers?name=some-handler-name" >
My form is a part of a system and located right on the same server. Basically its accessible via adress like
http://<server>/handlers?name=my-handler-with-form
But when I submit my form - nothing is posted to some-handler-name handler because my http-request receives code 302 (redirect).
Do I use correct address in action method (what I want is my form data to be posted to address like http://server/handlers?name=some-handler-name)?
Is it possible to post data to url that has query string parameters?
I guess that system intercept my postback and for some reason redirects it
Correct address is important
Yes, it is possible to post data with query params
There would be some redirect rule set at the server side. You would need to work with server side dev or read server side deployment/code documentation.
Related
When a client browser receives a 302 response, does the browser modify or ignore any parameters appended to the end of the URL?
For example, I have a server that redirects requests to a different URL but retains any parameters from the original URL and appends to the end of the new redirect URL. However, browser is not including the parameters in the new URL.
For example, if a request comes in to "https://server1.com/path1?filter=value", the redirect server responds with a 302 and "location: https://server2.com/path2?filter=value". But, issue is that the client browser seems to only recognize "https://server2.com/path2".
Should parameter values be tagged a different way in the response?
As noted by Remy Lebeau in the comments to the question, the browser does not modify the location URL in the 302 response. Rather, the issue was caused by the networking in AWS - I was using AWS Lambda to perform the re-direct by reading in the URL on the original request coming in and re-directing according to mapping in the function. First issue was that API gateway was stripping off the query parameters before it was hitting the Lambda function. Second issue was that the function read the "rawPath" attribute from the request, but this does not contain URL query parameters; the query parameters are contained in the "rawQueryString" attribute instead.
If I set a link in Backend to a specific content element on a page (http://www.test.url/example#999), is there any chance to get this anchor-id in the target template?
As already mentioned, the hash-value is not part of the http request.
Here is an example on how to access the hash on the client side via JavaScript: How to get Url Hash (#) from server side
It is of course possible to convert the hash to a get or post request on the client side.
I'm asking this one for the record:
So I have a client making an Ajax call and I'm trying to have the server handle it and redirect the client server-side.
The express docs make it seem res.redirect(path) is going to actually send a response from the server for the client to redirect(re-route).
e.g.
var path = 'http://localhost:8080/newRoute';
res.redirect(path);
//the client will now go to http://localhost:8080/newRoute
But it appears that this only tells the client to make another request to
the url given.(Which seems useless, but that is what my network requests are showing currently).
Many suggest to do the following to do an actual redirect server-side
var path = 'http://localhost:8080/newRoute';
response.writeHead(302, {'Location': path});
response.end();
So does this mean that that we need to change the header in order for the redirect work?
i.e.
res.location('http://localhost:8080/newRoute');
res.redirect('http://localhost:8080/newRoute');
But the above looks horribly redundant and makes res.redirect look like it wasn't intended for server-side redirects to a new page.
Yet the Express docs show an example like this:
res.redirect('http://google.com');
which I don't know how that could be interpreted any other way than "send the client to the page 'http://google.com' ".
Big Question:
So is res.redirect(path) suppose to handle server-side redirects? If not, what do we do?
The default process when authenticating user on OpenAM/OpenSSO works with a 302 http redirection, opening OpenAM/OpenSSO authentication formular. The original URL is stored into "goto" parameter, which allows OpenAM/OpenSSO to redirect the user back on orignal URL after correct authentication.
This works well when using HTTP GET method (i.e. when entering URL), but it is not suitable for POST method. For instance, if the session expires while the user posts a HTML form, the data are lost because HTML form inputs are not present in goto parameter.
Do you know it it is possible to configure J2EE Agent in order it re-posts user HTML form after valid authentication ?
Both the Java EE and the Web agents support post data preservation, see the documentation.
If I visit the link http://mega.1280.com/file/EKOZKE/, enter the captcha code and click the Download button, I can download the file.
I wonder if I can submit the form without clicking the 'Download' button? I mean typing the captcha code directly on the address bar and hit Enter?
I try http://mega.1280.com/file/EKOZKE/?code_security=xxxxxx where 'code_security' is the name of the textbox of the captcha code but it failed. Any ideas?
The form has a POST method. You can't emulate a POST request with a different url, that's what GET requests do.
Even if the server doesn't check the method of the request, you still have to provide every mandatory data. If you look at what is sent by the form, you'll see there are 3 other parameters (action, btn_download, file_id), and more importantly several cookies that the server need to recover your php session (PHPSESSID), which is in turn needed to match your security_code with the provided CAPTCHA.
Bottom line: you can emulate the request, but not by submitting a simple GET request. You have to use a real user agent, one that is able to send post requests and handle cookies.
...But of course, that's exactly what CAPTCHA are here to prevent you to do :-).
edit: to reply to your comment "I just want to find out the technique that this website use to submit form." :
This website doesn't submit the form, actually. It's your browser that submits the form, and it does so by conforming to HTML and HTTP standards. On the webpage, the form is coded
<form name="frm_download" method="post" action="">
So when you click on the "submit" button, your browser collects all the data from the inputs (text, hidden, whatever) and sends a HTTP POST request to the same url that the form originated from, with a bunch of HTTP headers (including a Cookie header that contains all the stored cookies information attached to this server domain) and a body containing the form data : a list of key/value pairs.
The server receives the request. It can check that it's actually a POST request. It can and will retrieve all submitted pairs of data (parameters). It can retrieve the cookies, and will do so to restore your php session. It will then compare your security_code parameter with the correct data stored in your php session. If the CAPTCHA matches, then it will send you a response containing the file pointed by your file_id parameter.