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.
Related
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.
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.
If I have a service running with a url pattern similar to below.
HOST/animals/{id}
If do a GET on this url with a non existent id for most Rest implementations I would expect to receive a 404 Not Found response.
If I do a GET request for (note the typo!):
HOST/animels/{id}
With a valid id I will also get a 404 response in most Rest implementations.
Obviously I can distinguish between the scenarios by looking in the response body but this would be custom behaviour for my API.
Is there an standard approach to this?
Maybe return method not allowed/bad request for non mapped urls (though this would be large change to expected behaviour)?
Or do we need 2 status codes for Not Found?
A scenario for something like this occurring is a typo in some documentation/implementation of a client.
If you treat the entire URL as an identifier that points to a resource, the two cases are the same.
Case-1: '/animals/{bad-id}'points to a resource that is not found.
Case 2: '/animels/{id}' points to a resource that is not found.
Thus both cases should be treated the same as 'NOT Found'
I am setting up a back end API in a script of mine that contacts one of my sites by sending XML to my web server in the form of POST data. This script will be used by many and I want to limit the bandwidth waste for people that accidentally turn the feature on without a proper access key.
I will be denying requests that do not have the correct access key by maybe generating a 403 access code.
Lets say the POST data is ~500kb of data. Does the server receive all 500kb of data when this attempt is made regardless of the status code?
How about if I made the url contain the key mydomain/api/123456789 and generate 403 status on all bad access keys.
Does the POST data still get sent/received regardless or is it negotiated before the data is finally sent.
Thanks in advance!
Generally speaking, the entire request will be sent, including post data. There is often no way for the application layer to return a response like a 403 until it has received the entire request.
In reality, it will depend on the language/framework used and how closely it is linked to the HTTP server. Section 8.2.2 of RFC2616 HTTP/1.1 specification has this to say
An HTTP/1.1 (or later) client sending
a message-body SHOULD monitor the
network connection for an error status
while it is transmitting the request.
If the client sees an error status, it
SHOULD immediately cease transmitting
the body. If the body is being sent
using a "chunked" encoding (section
3.6), a zero length chunk and empty trailer MAY be used to prematurely
mark the end of the message. If the
body was preceded by a Content-Length
header, the client MUST close the
connection.
So, if you can find a language environemnt closely linked with the HTTP server (for example, mod_perl), you could do this in a way which does comply with standards.
An alternative approach you could take is to make an initial, smaller request to obtain a URL to use for the larger POST. The application can then deny providing the URL to clients without an appropriate key.
Here is great book about RESTful Web Services, where it's explained how HTTP works: http://oreilly.com/catalog/9780596529260
You can consider any request as envelope, where on top of it it's written address (URL), some properties (HTTP Headers) and inside it there's some data (if request is initiated by post method). So as you might guess you can't receive envelope partially.
Oh I forgot, it's when you are using HTTP Post with standard HTTP header "application/x-www-form-urlencoded" but if you are uploading files (correspondingly using ""multipart/form-data") Django gives you control over streamed chunks of files using Middleware classes: http://docs.djangoproject.com/en/dev/topics/http/middleware/
Is it allowable to pass parameters to a web page through the URL (after the question mark) when using the POST method? I know that it works (most of the time, anyways) because my company's webapp does it often, but I don't know if it's actually supported in the standard or if I can rely on this behavior. I'm considering implementing a SOAP request handler that uses a parameter after the question mark to indicate that it is a SOAP request and not a normal HTTP request. The reason for this that the webapp is an IIS extension, so everything is accessed via the same URL (ex: example.com/myisapi.dll?command), so to get the SOAP request to be processed, I need to specify that "command" parameter. There would be one generic command for SOAP, not a specific command for each SOAP action -- those would be specified in the SOAP request itself.
Basically, I'm trying to integrate the Apache Axis2/C library into my webapp by letting the webapp handle the HTTP request and then pass off the incoming SOAP XML to Axis2 for handling if it's a SOAP request. Intuitively, I can't see any reason why this wouldn't work, since the URL you're posting to is just an arbitrary URL, as far as all the various components are concerned... it's the server that gives special meaning to the parts after the question mark.
Thanks for any help/insight you can provide.
Lets start with the simple stuff. HTTP GET request variables come from the URI. The URI is a requested resource, and so any webserver should (and apache does) have the entire URI stored in some variable available to the modules or appserver components running within the webserver.
An http POST which is different from an http GET is a separate logical call to the webserver, but it still defines a URI that should process the post. A good webserver (apache being one) will again make the URI available to whatever module or appserver is running within it, then will additionally make available the variables which were sent in the POST headers.
At the point where your application takes control from apache during a POST you should have access to both the GET and POST variables and be able to do whatever control logic you wish, including replying with a SOAP protocol instead of HTML.
If you are asking whether it is possible to send parameters via both GET and POST in a single HTTP request, then the answer is "YES". This is standard functionality that can be used reliably AFAIK.
One such example is sending authentication credentials in two pieces, one over GET and the other through POST so that any attempt to hijack a session would require hijacking both the GET and POST variables.
So in your case, you can use POST to contain the actual SOAP request but test for whether it is a SOAP request based on the parameter passed in GET (or in other words through the URL).
I believe that no standard actually defines the concept of "HTTP parameters" or "request variables". RFC 1738 defines that an URL may have a "search part", which is the substring after the question mark. HTML specifies in the form submission protocol how a browser processing a FORM element should submit it. In either case, how the server-side processes both the search part and the HTTP body is entirely up to the server - discarding both would be conforming to these two specs (but fairly useless).
In order to determine whether you can post a search part to a specific service, you need to study this service's protocol specification. If the service is practically defined by means of a HTML form, then you cannot use a mix - you can't even use POST if the FORM specifies GET (and vice versa). If you post to a web service, you need to look at the web service's WSDL - which will typically mandate POST; with all data in a SOAP message. Etc.
Specific web frameworks may have the notion of "request variables" - whether they will draw these variables both from a search part and a request body, you need to find out in the product documentation.
I deployed a web application with 3 (a mobile network operator) in the UK. It originally used POST parameters, but the 3 gateway stripped them (and X-headers as well!). So beware...
allowable? sure, it's doable, but i'm leaning towards the spec suggesting dual methods isn't necessarily supposed to happen, or be supported. RFC2616 defines HTTP/1.1, and i would argue suggests only one method per request. if you think about your typical HTTP transaction from the client side, you can see the limitation as well:
$ telnet localhost 80
POST /page.html?id=5 HTTP/1.1
host: localhost
as you can see, you can only use one method (POST/GET, etc...), however due to the nature of how various languages operate, they may pick up the query string, and assign it to the GET variable. ultimately though, this is a POST request, and not a GET.
so basically, yes this functionality exists, is it intended? i would say no.