Just want to say at the beginning. I'm really sorry if you will consider this as a duplicate but I'd like to ask you what is the middleware. I know stackoverflow has some similar questions but I'd be glad if you could answer this one. Also what is the .use ? Where do we use it? Thank you very much!
Middleware is a term that refers to request handlers that "pre-process" an incoming request. A given middleware will typically run on lots of incoming requests. Usually, it doesn't send the final response, it just does some setup or pre-processing on the request and then passes the request on to its eventual handler. There are thousands on things that people find to do with middleware.
The general idea is that it's easier to put middleware in one place and configure it to apply to lots of requests rather than have to add it to every single request handler that its supposed to apply to.
I'll offer a few examples:
Check to see if the requester is authenticated/loggedin on the site. If not, then redirect to the login page. If so, then pass the request through to the actual page request handler.
Log usage or performance statistics.
Pre-parse query parameters so they're already parsed for the request handler
Pre-parse post bodies so they're already parsed for the request handler
Preset desired cross origin headers for the response
Hopefully, you can see the general idea that middleware is often used as pre-setup work that can be done in one place rather than having to be added to every single request handler.
Keep in mind that middleware can be configured to determine which incoming requests it gets run for. It can be only for a single URL (not typical), a whole group of URLs such as everything start with a particular path, or all URLs on the entire site.
Related
I have an express API with a bunch of routes.
routes.get('/', perms('read', 'document'), r(CRUD.getAll))
routes.get('/search', perms('read', 'document'), r(CRUD.search))
routes.get('/:id', perms('read', 'document'), r(CRUD.getById))
I made sure to have /search above /:id, however, when a new request comes in to /search, I see both endpoints getting a hit (I added a console.log inside of each function).
I tried flipping the two and in that case, only /:id gets a hit.
Any idea of why this may be happening?
Think about Express routing as an array of handlers (middlewares), that have a matching rule (url). When a request comes in, the router starts checking each item in the array from the beginning. If it matches the rule, then the handler is run (some don't have conditions, so they just run on each request :)). The request chain does not end when a single url is matched! You can execute multiple handlers on the same request (and that's exactly how middlewares work).
Therefore, it really depends on what happens inside your handler. You can tell it to continue with the next item in the list, and if there's a match - the next handler will be executed (like /search and /:id, which will be search again).
Make sure you end your response. Beware if you call next and with what parameters. Post some samples of the handlers in order to debug it more :)
please forgive me if my question sounds naive. I researched on google, and several forums, but couldn’t find anything that is clear.
Here is my dilemma,
Step 1 -> Node.js Server is listening
Step 2 -> User on page ‘/new-users’. (POST, ‘/signup-controller)
Step 3 (& maybe Step 4) -> Id like to know what happens here, before the server decides where to take the data.
On step 1, Was the server listening to the local storage to see if any new requests are there?
Or, does it ‘directly’ receive the request in step 3?
I’ve always been under the impression that servers just listen to changes. Meaning it does not literally ‘receive’ req or res data.
Thanks a lot for reading my question and I look forward to any feedback.
EDIT: to clarify, does the client walk up to the server directly and hand over the data’s, hand to hand, or does the client store the data at some ‘locker’ or ‘location, and the server notices a filled locker, hence triggering the subsequent events?
No it will directly receive the request data and if you are using framework like express in node then you can use middleware to validate or check request data and move forward
The server only listen for a request, not for response
when it finds a request (req), operates with this request and bases od that must deliver a response (res) with data, files, error.. whatever..
The server receives a POST og GET (Depending on the METHOD attribute in the FORM tag) - If you want to implement some logic to decide where to put the data, it should be done by the server, analyzing the data. Hidden input tags (Type="hidden") could assist supplying info. Like a hidden input tag saying "NEW" or "EDIT" and the "ID" to example.
Using an AJAX method instead lets you negotiate with the server before the final POST.
hth.
Ole K Hornnes
On step 1, Was the server listening to the local storage to see if any new requests are there?
no, the server not listening the local storage, it listening the server port. and waiting the request.
does it ‘directly’ receive the request in step 3?
Server will receive when client send a request, in your case , step 2
The data from the form is formatted into an HTTP request and sent over the network to the server directly. The server receives it from the network, puts it into memory (RAM), and calls your handler.
A TCP connection (that HTTP is built on) transmits sequences of bytes - that's why it is called a stream-oriented transport. This means you get the bytes in the same order you've sent them. An HTTP request is just a piece of text which looks similar to this:
POST /signup-controller HTTP/1.1
Host: localhost:8080
Content-Type: application/json
Content-Length: 17
{"hello":"world"}
Note the blank line between the headers and the body. This gap is what allows Node.js (and HTTP servers in general) to quickly determine that the request is meant for localhost:8080/signup-controller using the POST method, without looking at the rest of the message! If the body was much larger (a real monster of a JSON), it would not make a difference, because the headers are still just a few short lines.
Thus, Node.js only has to buffer that part until the blank line (formally, \r\n\r\n) in memory. It gets to that point and it knows to call the HTTP request handler function that you've supplied. The rest - after the line break - is then available in the req object as a Readable Stream.
Even though there is some amount of buffering involved at each step (at the client, in switches, at intermediate routers, in the server's kernel, and finally in the server process), the communication is "direct" - one process on one host communicates with another process on another host, without involving the disk at any point.
The scenario is to save the data in cache. We have numerous express routes written with complicated logic.
I have to find a way to save the response data in cache. I cannot go to each and every route and check whether this needs to be saved and save the data before sending the response. (If no other go, then this may be the way)
I have tried the following approaches.
https://nodejs.org/api/http.html#http_event_close_1 - using 'close' or 'finish', which fires after sending the response would do the trick. But there is no way I could get the response data in these events.
Also my node version is v0.10.31
Thought of using app.all('*', callback), but i am not sure how to catch the response data for cacheing.
Finally i thought of adding a second callback for routing, app.VERB(path, [callback...], callback), but upon returning the response in first callback, second callback is never called.
Hoping there is a solution for this, and I am stuck in this for more than a week.
The reason why adding logic into each and every routes is a tedious job is that, I need to add a configuration entry specifying which route needs to be cached with an expiry time.
Response needs to be cached in redis server. A cache key will be generated based on the route data and query strings. All those complete user specific information will be saved in a key.
So when the user hits the same route the key will be generated to check if it already exists using app.use and the data will be served without precedding to the successive middlewares.
Define a callback middleware as,
var storeResponseMiddleware = function(req, res, next) {
console.log("storing data in redis....")
..........more stuff
}
Add it to expressJs app as,
app.use(logicRoute)
app.use(storeResponseMiddleware)
Now, for all the responses storeResponseMiddleware will be called. you must call next() inside the route handlers.
What is difference between
HTTPPOST
HTTPDELETE
HTTPPUT
HTTPGET
Normally used post and get method for submit form and i know them very well but want to know with delete and put method when and why they can be used to improve programming skills
What the different methods do depends entirely on how the remote web server chooses to interpret them. There is no fixed meaning. A server does not care if it sees GET or POST; rather, the code that ends up being executed to service the request does (and can decide to do anything, since it's code).
The HTTP protocol gives an official guideline for what kind of action each verb is supposed to trigger, which is:
GET: retrieve a resource
PUT: replace a resource with another, or create it if it does not exist
DELETE: remove a resource if it exists
POST: might do anything; typically used to "add" to a resource
However this mapping is ultimately governed by application code and is typically not respected by web applications (e.g. you will see logical deletions being enacted with POST instead of DELETE).
The situation is better when talking about REST architectures over HTTP.
In a nutshell:
GET = fetch a resource.
POST = update a resource.
DELETE = delete a resource.
PUT = create/replace a resource.
In HTML, only GET and POST are allowed. A typical web-development HTTP server will do nothing unless you have code (or configuration) to specify what you want it to do with the different HTTP methods.
There's nothing stopping you from updating user data in response to a GET request, but it's not advisable. Browsers deal with GET and POST differently, with respect to caching the request (a cached GET will automatically be reissued, but a cached POST will prompt the user to allow it to be resent) and many HTML elements can issue GETs, making them unsafe for updates. There are other HTTP methods too http://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol.
Many people who claim to be RESTful will confuse HTTP POST and PUT with SQL UPDATE and INSERT. There isn't a direct correlation, it always depends on context. That is, what POST means depends entirely on the resource that you're interacting with. For example, creating a new entry on a blog could be a POST to the blog itself, or a PUT to a subordinate resource. However, a PUT, by definition, must always contain the entire resource.
Typically, you would not allow a HTTP client to determine the URI of a new resource, so a POST to /blog would be safer than a PUT to /blog/article-uri although HTTP does cater for appropriate responses should the server be unable to honour the intended URI. (HTTP is just a specification, you have to write the code to support it, or find a framework)
But as you can always achieve a PUT or DELETE use-case by POSTING to a parent resource responsible for its subordinates (i.e. POSTing a message to /mailbox instead of PUTting it at /mailbox/message-id), it isn't essential to expose PUT or DELETE methods publicly.
You can improve your programming skills by adopting REST principles to improve the visibility of the interactions within a system, it may be simpler to contextualise your interactions in terms of REST by having a uniform interface, for example.
REST is not HTTP though: http://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm.
I am writing a web application that submits a form (one of its fields is mulitpart/form-data, so obviously POST must be used and not GET, since the files might be really big). One of the fields is kinda transaction/upload_id and the other is obviously the file contents. While uploading, a progress bar must be displayed.
The known fact says that the order of parameters is undefined in general, meaning that any of (file content / upload_id) might come first.
Is there any acceptable / recommended way to cause the browser to send the upload_id before sending the file content?
Is it a considered a correct implementation - to expect the upload_id to come first OR there is a better / most common / more correct way to handle the problem? In that case - it would be fantastic to hear some details.
Update: my server-side language is Java/Servlets 3.0
Well, the better answer (without utilizing filters) would be to publish the upload_id(s) as a part of the URL (after '?'), even when issuing a POST request. In that case, they will be always processed ahead of files' contents.
Using servlets as well, and in my case I wanted to run my CSRF filter in my servlet before I started streaming the file: if the filter failed, I can kill the request before I've uploaded my 20gb video file, as opposed to the default PHP implementation where the server only hits your script AFTER its parsed the entire request.
Its been a bit of a hack on my part, but in the couple of cases I've had to do this I've cheated and put the non-file request parameters into the URL and in every case (using pretty much every browser I've tested with) an Iterator over the request parameters on the server (I'm using commons fileupload in streaming mode) has received the non-file request parameters first before the file data was received. Somewhat fragile, but not unworkable.
I'm assuming that if you order your request parameters with the file <input> as the last item you'll get the same behavior.
You shouldn't have to worry about the order in which the parameters are sent. If so, then your server-side code is very brittle.
A multi-part request will contain the field name of every form field that is passed in. Use the name to reference that field regardless of the order it was sent in.
If you are parsing the post body by hand, I suggest you look at existing projects like Apache FileUpload which abstract that away.