I use SoapUI to send HTTP and SOAP requests. There is an URL like this: https://mydomain/response? , where a HTTP request should be posted. URL in raw request view it appears without question mark. I tried to provide it in URL encoded(%3F) form too, but it is not resolved, it points to a different URL.
This is an example of a GET string.
Anything after the "?" will be the parameters.
You don't have anything after the "?". Thus no parameters.
For some reason, this makes soapui remove it. But it really should be without any consequence. Both https://mydomain/response? and https://mydomain/response will reach the same endpoint with no parameters.
Related
I have a URL abc.com/#cancel. In my servlet I need to store #cancel for future use. I have already tried HttpServletRequest getRequestURI() and few other options. But don't see this value in request object. How do I get this value.
In my application I am using GWT which uses rpc calls and rpc request is made based on the hash tag value. eg: mydomain.com/#profile, forwards the request to profile.rpc. In my case I am intercepting this call with a filter which does some basic check and then I want to forward the request again to mydomain.com/#profile. but I am not able to find #profile in request object. Hope this explains my question and what I am looking for.
You cannot get the fragment part of a URL server side, as the browser won't send it to the server.
Eg: User click a link to http://www.example.com/foo#bar. Browser connect to www.example.com and send:
GET /foo HTTP/1.1
Host: www.example.com
Hash(#) is used to separate fragment from Url. Fragment is an optional part of the URL and is used to address a particular part of a resource.
please see below links
http://www.skorks.com/2010/05/what-every-developer-should-know-about-urls/
URL fragment (#) allowed characters
List of valid characters for the fragment identifier in an URL?
request.getRequestURI() will gives you the url eg:abc.com/#cancel.
String url1=request.getRequestURI();
url1.split("/");
Found out that fragmented URL doesn't come in request, when we do response.sedRedirect(), browser doesn't remove the fragmented part from browser URL bar. But not sure how this happens. Anyways in my case instead of posting request to another JSP and then submitting the form to different URL, I am directly doing response.sendRedirect(), which doesn't remove the fragmented part, so its working now :)
I have been reading on SAML 2 binding mechanism. It says below :
HTTP REDIRECT VS. POST BINDINGS: Both SPs and IDPs can transmit and receive messages using redirect or POST bindings. Due to the limitation of URL lengths in certain scenarios, HTTP Redirect is usually used when passing short messages, and HTTP POST is used when passing longer messages.
I am unable to understand how a response with the same length can be longer in redirect than it is in post. I think I am missing something very basic. Could anyone help to clear that ?
Redirects utilize the querystring to pass data, which has a size limitation that is not present in a post.
From w3schools:
Example Get:
/test/demo_form.asp?name1=value1&name2=value2
Example Post:
POST /test/demo_form.asp HTTP/1.1
Host: w3schools.com
name1=value1&name2=value2
the parameters for a get are located within the URL itself, which has a size limitation of 2083 characters (there is some variation to this number). For a post, the information to go along with the post is in the actual body of the message, rather than the URL.
Basically you get more "room" in a post, as you're not going to hit a size restriction on URL because your information is in the body - unless your URL is already that long which would mean it'd be an issue for gets or posts.
Why is the redirect url is of longer length?
I think you might be misunderstanding, it's saying you get less room for a redirect than a post, not more/longer. Gets have a size restrictions, posts do not, or at least it's a configurable setting on the server and has a larger "higher end" than a get request would.
I want to redirect my users browser using HTTP code 303 to a GET URL that I secure using HMAC. Because the request will come from the users browser, I will not have fore-knowledge of the request headers. So I am generating the HMAC hash using the values of the HTTP method and URL only. For example, the URL I want the browser to do to might be:
GET /download
?name=report.pdf
&include=http://url1
&include=http://url2
This create report.pdf for me, containing the contents of all the urls specified using the include query param.
My HMAC code will change this URL to be
GET /download
?name=report.pdf
&include=http://url1
&include=http://url2
&hmac-algorithm=simple-hmac
&hmac-signature=idhihhoaiDOICNK
I can issue HTTP 303 to the user using this URL, and the user will get their report.pdf.
As I am not including the request headers in the signature, I am wondering two things:
1) Can a would-be attacker take advantage of the fact that I am not signing the request headers?
2) Is there a better way to achieve what I am trying to do?
When I realised that what I am talking about here is a signed URL, I checked the Amazon Docs and found "REST Authentication Example 3: Query String Authentication Example" in this document: http://s3.amazonaws.com/doc/s3-developer-guide/RESTAuthentication.html.
This example is about a signed URL for use through a browser. About signing the headers, the document says:
You know that when the browser makes the GET request, it won't provide a Content-Md5 or a Content-Type header, nor will it set any x-amz- headers, so those parts are all kept empty.
In other words, Amazon leave the headers out of the signature.
Amazon make no mention of potential security holes, so until I hear otherwise (or get hacked :) ), I will assume my approach above is fine.
Can I detect from the URL of the request that the operation requested is:-
Download.
Registration.
Streaming.
Payment.
Or Other else..?
Somebody told me that request contains these characters : '?' '=' is for streaming requests.
Not reliably. You might be able to guess based on common words used in the URLs for different requests, but HTTP specifies none of what you're asking when it comes to URLs.
'?' and '=' are commonly present in a request that has parameters. But that could be anything.
Is this possible.. for example, imagine I respond to a request with a 302 (or 303), and I inform the browser to do a request to a given location.. is there a header that I can send with the HTTP 302, so that the subsequent request from the browser would include that header?
I know I could do this with the location header, as in redirect and specify the information in the url as a query string.. but I'm wondering if there is a better way.. it seems that it should be a legit scenario..
'Content has moved, go here .. oh and you'll want to take this with you to give to the redirect location'
I'm guessing a big fat no!
Thanks in advance.
Edit
The reason for this is in respect to PRG patterns, where you have a GET url and POST url, given that you post data and it isn't acceptable, the server redirects you to the GET, and does some 'magic' in order to 'send data' to that GET, using most often session state to store a variable.
However this can breakdown in scenarios where many of these PRG requests are happening, granted this isn't a common scenario and generally nobody need worry about this.. but if you do- you'll need a way to identify the requests, this can be done with query string parameters send in the 302.. so that a specific entry can be put in session state according to that request.
The question was regarding trying to remove the 'request key' from the url, and making it more implicit.. cookies 'appear' to work, but they only make the window for screw ups smaller.
It would be great to say when you go the 'location' i've specified, send these parameters.
Edit
Just to note, I'm not trying to get the browser to send arbitrary headers to the location, but if there is ANY headers designed to hint the context of the request (like the querystring parameters could).
A redirect response itself doesn't contain any data. You can redirect using a URL with query parameters, but the new "location" will need to know how to consume those parameters.
No, that’s not possible. You cannot force the client to something. You just can say “this is not the right location, but try that location instead”. But it’s not guaranteed that the client will send the same request or another request to that new location. And telling the client to add a specific header field in that subsequent request to the new location is also not possible.