New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Why make the way to override method exclusive? #8
Comments
Because you can app.use this module three time with three different configurations if you want multiple ways. We don't duplicate features of express, which lets you do the union. see the example: https://github.com/expressjs/method-override/blob/master/README.md#multiple-format-support Let me know if I'm misunderstanding your question as well. |
Another option is to
and use the older version. Version 2 is more extensible and fixes a security issue, since it was not backwards compatible. You can do all three of those options above using this module, and in fact, express 3 does use v2 of this module. |
Thank you for your swift reply and thorough explanation, Doug. Yes, you've understand my question well. I've switched to method-override@1 after I posted this question. I'd say my expectation of this module was that it's an independent version of connect's method-override along with possible fixes. |
Yes, it is the exact version that is used by connect's methodOverride (check out the source https://github.com/senchalabs/connect/blob/2.x/lib/middleware/methodOverride.js), but has been enhanced and change to allow you to program it to look at anything and not only what was built-in. The body check was removed as a built-in because it caused endless issues and confusion, especially when it altered the body. In the readme there is code that shows how to use the body method with v2 if you like as well. In general these modules are considered"core" modules and new features are only added if it's absolutely impossible to do what you are looking for, which isn't the case here. Also, let me know if you would like me to show the code you would need to use v2 to do what you wanted in the original post. |
Yeah, I did see the I'd been a Ruby on Rails developer long before I switched to Node and Express. To me, and I'd say to most of those developers who have experienced both, Express is the Node version of Rack which we can pile middlewares on top of it and implement web applications we want. I must say that I understand your concerns. Advancing without breaking anything is ideal but not always true. It's just surprises a lot at first. I did have found the code in readme that make up for Thank you for your replies once again. Like Breaks or maintains backward compatibility, so be it. method-override is a small part of Express 4 (not literally, I know), contains less than a hundred lines of code. Writing tens more to mimic the behaviour of v1 to use v2 is just absurd. I'll use v1 for now, and see if I will get the chance to upgrade my application completely by removing those Thanks Doug. |
haha, yea, things do change eventually :) One of the reasons we broke out all those connect middleware into their own modules is to be able to mix-and-match different versions of them, while being able to upgrade Express.
Pretty much.
So, this was what I was trying to help you understand: you can use a middleware more than once and it becomes a "union" of the middleware. This is why we made the var express = require('express')
var bodyParser = require('body-parser')
var methodOverride = require('method-override')
var app = express()
// Parse the needed body types
app.use(bodyParser.urlencoded({ extended: false })
app.use(bodyParser.json())
// Allow method override, supporting the header and body at the same time
app.use(methodOverride('X-HTTP-METHOD-OVERRIDE')) // look at the header
app.use(methodOverride(function(req, res){ // ALSO look in the body
if (req.body && typeof req.body === 'object' && '_method' in req.body) {
// look in urlencoded POST bodies and delete it
var method = req.body._method
delete req.body._method
return method
}
}))
app.use(function(req, res){
res.type('text')
res.send('You tried to ' + req.method + ' ' + req.path);
}) With the example above, it supports both the
haha. So yes, it is 100% possible to use v2 to do anything you want, including mimic v1, but yes, the reason that it only does header and query "out-of-the-box" is because they are the only two ways that make any sense, so we wanted to make it easy to do the right thing :)
In the end, this is the best way :) Personally I only use the query string (since from an HTTP level it makes sense to me for the method to appear in the URL, since that is included in the very first line of the HTTP request:
It's my pleasure. I'm here to help :) |
Came here reading through old issues in search of the arguments against hiding the method in a form input (as Rack does, and therefore Sinatra and Rails). Really appreciate the background info, and am now a convert to the query string method, since that makes it visible right at the top of the raw HTTP request. |
AFAIK, there are at least three ways to override request method:
{ X-HTTP-METHOD-OVERRIDE: PUT }
header?_method=PUT
req.body._method
In my not so complicated application which was built with express 3, there are two ways of them involved already. And as far as I can tell, we can't ditch NO. 2 and 3 completely unless the application we are implementing is totally asynchronized with JavaScript.
So why make the way to override exclusive?
The text was updated successfully, but these errors were encountered: