Why make the way to override method exclusive?

[expressjs]

Why make the way to override method exclusive?

[dougwilson]

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.

[dougwilson]

Another option is to

npm install method-override@1

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.

[cyjake]

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.

[dougwilson]

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.

[cyjake]

Yeah, I did see the supports method, which I believe is a footprint of the original connect method-override. Obviously a lot of changes took place since then.

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 req.body._method override. But I gave it up soon after I checked method-override@2 and learned that the provided getter will be the only getter, which means no more X-HTTP-METHOD-OVERRIDE. Unfortunately I use both. That leads to this issue.

Thank you for your replies once again. Like method-override@2, I wasn't expecting to hear for the maintainer of Express 4 this much either.

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 req.body._method.

Thanks Doug.

[dougwilson]

Obviously a lot of changes took place since then.

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.

Express is the Node version of Rack which we can pile middlewares on top of it and implement web applications we want.

Pretty much.

I did have found the code in readme that make up for req.body._method override. But I gave it up soon after I checked method-override@2 and learned that the provided getter will be the only getter, which means no more X-HTTP-METHOD-OVERRIDE. Unfortunately I use both. That leads to this issue.

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 getter exclusive: because Express give you the ability to union, so we don't want to duplicate that here. For example (I'm sorry I took so long to provide a code example, but I have only been using my phone this whole time due to a holiday):

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 req.body._method and the header X-HTTP-METHOD-OVERRIDE with v2 code. I hope this help explain what I said way above about "Because you can app.use this module three time with three different configurations if you want multiple ways".

Writing tens more to mimic the behaviour of v1 to use v2 is just absurd.

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 :)

I'll use v1 for now, and see if I will get the chance to upgrade my application completely by removing those req.body._method

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: POST /form?_method=DELETE HTTP/1.1, haha; the header is also fine). The most important part is to be able to know the URL/method to route before needed to parse the (potentially large) body.

I wasn't expecting to hear for the maintainer of Express 4 this much either. [...] Thanks Doug.

It's my pleasure. I'm here to help :)

[brookr]

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.