I'm using BITS to make requests to a ASP.NET MVC controller method named Source that returns a FileResult. I know the type FilePathResult uses HttpResponse.TransmitFile, but I don't know if HttpResponse.TransmitFile actually writes the file to the response stream regardless of the request type.
My question is, does FileResult only include the header information on HEAD requests, or does it transmit the file regardless of the request type? Or, do I have to account for HEAD requests myself?
The result is forced to react on a request by YOUR ACTION CODE. If you do not do anything special on different request types (e.g. [HttpGet]-Attribute, HttpMethodConstraints in the Route, etc...) The file is just written to the response stream.
Related
We are trying to write a iRule for the BIG-IP universal persistence module.
Our mission is to extract and persist from a HTTP response payload/body an application unique identifier (something like a seesionid for us).
Then use it in a consecutive HTTP requests.
Note, this unique identifier return in text/xml/soap-xml response formats and there is no cookie involve here.
We're having problem to write the TCL code for the extraction of our custom unique identifier from the HTTP response payload/body.
We have checked these manuals and did not find example for this kind of functionality:
https://devcentral.f5.com/wiki/iRules.HTTP_RESPONSE.ashx
https://devcentral.f5.com/wiki/iRules.HTTP__payload.ashx
Thanks.
Here's an example with jsession IDs that should get you started with basic persistence flow, and this example gives you an idea on how to work with payload data.
first of all I'd like to thank the team for this amazing project, it is indeed exiting to be able to start writing server-side software in Swift.
I'm successfully running a POC using PerfectServer on an Ubuntu VM and working on the API to interact with the mobile client.
There is one aspect I didn't quite understand yet, and that is accessing the request body data from my PerfectServer Handler.
Here is the workflow I have in mind:
The client submits a POST request to PerfectServer including some
JSON encoded body data
Once that hits the "valuesForResponse:" of
my server side Handler, I retrieve the WebRequest representation of
my request successfully
The request object does expose a many
properties of the HTTP request, including headers and the url-like
formatted query parameters.
Unfortunately, I cannot see a way to retrieve the underlying request body data. I would expect that to be some kind of public properties exposing the raw data that my handle can retrieve and decode in order to process the request.
The only example provided in the Examples workspace that comes with the project and sends a POST request that includes a body is in the project Authenticator. Here the HTTP body part takes the form os a UTF-8 encoded string where the values are query-params-like formatted.
name=Matteo&password=mypassword
This gets somehow exposed on the server handler by the WebRequest "param" property, that in the inner implementation of HTTPServer seems to expect an "&" separated string of key-values:
What I would expect is to have a way to provide body data in whatever form / encoding needed, in my case a JSON form:
{"name":"Matteo", "password":"psw"}
and be able to access that data from the WebRequest in my handler, decode it and use it to serve the request.
To summarise, I assume you could say that a WebRequest.bodyData public property is what I am after here :).
Is there something I am missing here?
Thanks in advance for any clarification!
I am very new to web api stuff:
I am getting an error
406: Not Acceptable
error message in asp.net web api rest service.
In my rest service I’m using media format for my customized XML output, to get customized output.
I’m registering my formatted media in Global.asax page.
GlobalConfiguration.Configuration.Formatters.Clear();
GlobalConfiguration.Configuration.Formatters.Add(new mynewformat());
all my methods are post methods with typed object as parameter and parameters are accepts from body.
Whenever I try to test the service… Getting 406: Not acceptable error message.
can anyone please help me ... what could be the reason for this....???
I did notice couple of interesting points here...
If I’m commenting below line then I’m getting 200 (OK) status code (which is fine.)... but format is not applying to output.
GlobalConfiguration.Configuration.Formatters.Clear();
If i'm removing parameters in my service method.. Then its working
fine..
I request everyone.. Please guide me what could be the reason/work around/solution/fix..for this issue.
Note:I don't want accept parameters from URI so i made it to accept from frombody only.
Thanks.
There is a lot more to implementing a custom format than just adding it to the configuration formatters. It starts with having to change the media-type header to a new custom type of your choosing (like "application/myNewFormat") for all requests, for the client. On the back end, you have to implement a new MediaTypeFormatter that can handle the serialization. This involves a bit more of code.
A good example of this resides here, it can easily be stripped to boiler-plate code:
http://www.codeproject.com/Articles/559378/Implementing-Custom-Media-Formatters-in-ASP-NET-We
As we all know, file uploading is most often accomplished using POST method. So, why can't the GET method be used for file uploads instead? Is there a specific prohibition against HTTP GET uploads?
GET requests may contain an entity body
RFC 2616 does not prevent an entity body as part of a GET request. This is often misunderstood because PHP muddies the waters with its poorly-named $_GET superglobal. $_GET technically has nothing to do with the HTTP GET request method -- it's nothing more than a key-value list of url-encoded parameters from the request URI query string. You can access the $_GET array even if the request was made via POST/PUT/etc. Weird, right? Not a very good abstraction, is it?
Why a GET entity body is a bad idea
So what does the spec say about the GET method ... well:
In particular, the convention has been established that the GET and HEAD methods SHOULD NOT have the significance of taking an action other than retrieval. These methods ought to be considered "safe."
So the important thing with GET is to make sure any GET request is safe. Still, the prohibition is
only "SHOULD NOT" ... technically HTTP still allows a GET requests to result in an action that isn't
strictly based around "retrieval."
Of course, from a semantic standpoint using a method named GET to perform an action other than
"getting" a resource doesn't make very much sense either.
When a GET entity body is flat-out wrong
Regarding idempotence, the spec says:
Methods can also have the property of "idempotence" in that (aside from error or expiration issues)
the side-effects of N > 0 identical requests is the same as for a single request. The methods GET,
HEAD, PUT and DELETE share this property.
This means that a GET method must not have differing side-effects for multiple requests for the
same resource. So, regardless of the entity body present as part of a GET request, the side-effects
must always be the same. In layman's terms this means that if you send a GET with an entity body
100 times the server cannot create 100 new resources. Whether sent once or 100 times the request must
have the same result. This severely limits the usefulness of the GET method for sending entity bodies.
When in doubt, always fall back to the safety/idempotence tests when evaluating the efficacy
of a method and its resulting side-effects.
In case of GET Method
Appends form-data into the URL in name/value pairs and length of URL is limited(3000 characters).
File content can't be put inside a URL parameter using a form.So use POST
In Get method, the value of action, appends a `?' to it, then appends the form data set, encoded using the "application/x-www-form-urlencoded" content type. The user agent then traverses the link to this URI. In this scenario, form data are restricted to ASCII codes.
So, that file upload is not possible in GET Method
In Kohana 3.1.x framework.
What are the benefits to send data with internal requests like this
$post = Request::factory('module/data')
->method(Request::POST)
->post(array('some' => 'random data'))
->execute()
->response;
if you could simply send data like this
Module::instance()->data(array('some' => 'random data'));
In this example Module is a random module and data is some random method.
I'll call this Module via ajax and internal requests. I'm planning to design RESTful API.
QUESTION IS: Why use HMVC instead of just directly using an internal class API
Because they're internal requests, there is no additional HTTP request being made.
You might want to take a look at Request_Client_Internal and compare it to Request_Client_External. After that you should feel enlightened :)
Edit:
You should know that AJAX requests aren't the only "external HTTP requests". cURL, PECL HTTP, file_get_contents() and other PHP functions will also send an external HTTP request (imho you should read the RFC 2616 to understand how HTTP actually works).
With HMVC calls you can use the same controller for both Ajax and internal requests. Also, it can handle a standard (non-ajax) http-requests, form submits for example. All-in-one solution, single entry point.
If you dont want HMVC calls, you will require one call for internal request (somewhere in base controller) and another one - in a special Ajax controller. Also you may have a problems with a data rendering (usually HMVC and ajax calls are using different templates). Its not DRY.
I would comment on the above, what biakaveron said, but I can't yet, so I put it as an answer.
#stacknoob: Could you use Module::instance()->data(array(...)) as controller's action? You could - with some extra code.
Instead, what biakaveron already said, you can keep your code logic and have the action return the same result for AJAX and HMVC requests. In one place. DRY + KISS.