I am trying to understand the functionality of WSGI and need some help.
So far I know that it is kind of a middleware between servers and applications, used for interfacing different application frameworks (that reside in the server side) with the application, provided that the framework in question has a WSGI adapter. Continuing the theoretical part, I know that for server to communicate with the application, server calls a callable (that takes two arguments: environment variables and start_response function). Here start_response function is provided by the server (?) and used by the application with a response status and header followed by response body.
I understand little of what I wrote above, so here are newbie questions:
1) What is the general call flow ? Application will provide the server with a callable and then server would invoke the application using that callable and using env_vars and start_response function as arguments?
2) What confuses me the most is that the application is sending the request headers and then it sends the response body as well. What type of request is this ?
Please enlighten me as I am unable to get my head around this stuff.
Thanks!
The call flow is as follow:
The server got a http connection,
server parsed the http request line and headers, read the body,
server populates the environ dict according to the request,
server calls application callable with environ and start_response as arguments,
application callable calls start_response with response status and response headers,
application return response body to the server,
server send the http response to the client.
For your second problem, the request/response is an interface defined by wsgi protocol (e.g. status = '200 OK', response_headers = [('Content-type', 'text/plain')]), not the same thing with http request/response.
You can browse the stand library module wsgiref as reference.
Related
So, in the browser, fetch returns a promise that returns a promise. The first for an OPTIONS http call which is sometimes a 'preflight CORS' thing, and the second a response to your original request.
In Node.js when you use the https.request() function or many of the libraries, this pattern isn't followed. Is that because there is no options call when you make an http call from a server?
How to get HttpRequestContext when I am using Self Hosted Owin?
My class is being called by ApplicationInsights and not by a controller, so I don't have access to any context.
Is there any way similar to what we do using HttpContext?
There is no static class to retrieve the request when using OWIN self hosted, because you are essentially in a console application, which is unaware that you wrote code that receives http requests.
Owin is a pipeline. The request is passed from middleware to middleware by calling the next middleware with a context parameter containing the request (and the response for that matter).
Each middleware registered in the pipeline can inspect the request on the way in, in their registration order, and call the next middleware before processing the response.
It is very easy to write your own middleware, register it in the pipeline, and inspect the request object for each request coming in.
Take a look here if you need a quick code example : http://benfoster.io/blog/how-to-write-owin-middleware-in-5-different-steps
I have a NodeJS proxy service which obfuscates some data and forwards the request to another service. Due to some details surrounding how we, and the servcie we're proxying to handle authentication, we need to remove a certain header from the incoming request before we proxy it.
I saw some documentation about request such as: "This object is created internally and returned from http.request(). It represents an in-progress request whose header has already been queued. The header is still mutable using the setHeader(name, value), getHeader(name), removeHeader(name) API."
But then the same documentation says the headers are read-only. I also saw some documentation that showed those methods (removeHeader, etc) being available, and others that don't list it.
Can someone tell me if there's a way to remove a header from the request object itself before copying the headers over? If not is there an easy way to copy over all the headers except the one I want to leave out?
Came here looking for a solution, but for node-http-proxy. You can do it by listening to proxyReq event on the proxy and then calling removeHeader on the proxy request object, like so
myProxy.on("proxyReq", function(proxyReq, req, _, options) {
proxyReq.removeHeader("x-my-header");
});
I need to make an HTTP request to a service that returns malformed headers that the native Node.js parser can't handle. In a test script, I've found that I can use the http-parser-js library to make the same request and it handles the bad headers gracefully.
Now I need to make that work within the Electron app that needs to actually make the call and retrieve the data and it's failing with the same HPE_INVALID_HEADER_TOKEN. I assume, for that reason, that the native HTTP parser is not getting overridden.
In my electron app, I have the same code I used in my test script:
process.binding('http_parser').HTTPParser = require('http-parser-js').HTTPParser;
var http = require('http');
var req = http.request( ... )
Is there an alternate process binding syntax I can use within Electron?
This was not an electron issue. My app makes several different requests and most of the are to services that return proper headers. Originally, I was using the request-promise library to handle all calls, but I needed to modify the one call that returned bad headers.
The problem was that I was still using request-promise for the other calls and that library conflicts with the custom code I had to write to deal with the malformed headers. Once I modified my custom code to handle all requests, things worked much more smoothly.
I built an API using AWS API Gateway and Lambda, now I am writing end to end tests, I am using Promise from bluebird and request, so I promisified request like this:
Promise.promisifyAll(require('request'));
Promise.promisifyAll(request);
Now when I make requests (POST, PUT, GET), using request.methodAsync, the method is not recognized by the API Gateway !
I launched Jasmine with :
NODE_DEBUG=request jasmine
I can see the method = 'POST' or whatever, but the API still not recognize the method of the requests I am making with the promisified request ! any one run into this situation ?
Hi I'm from the Api Gateway team. As long as the request is sent to a valid resource path / HTTP method pair on a deployed API, Api Gateway will accept it. Please note you'll need to put the stage name as the first path part in the URI (see example in the Api Gateway console on the Stages page).
If you're invoking the right API resource, the issue sounds like a client-side bug.
Jack