# Setting +input+ headers for an upstream server depending on the request's path+method

**URL:** <https://www.ruby-forum.com/t/setting-input-headers-for-an-upstream-server-depending-on-the-requests-path-method/215597>\
**Category:** NGINX\
**Created:** [January 9, 2012, 10:47pm UTC](https://www.ruby-forum.com/t/setting-input-headers-for-an-upstream-server-depending-on-the-requests-path-method/215597 "2012-01-09T22:47:40Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![luislavena](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/l/0ea827/32.png) [@luislavena](https://www.ruby-forum.com/u/luislavena)\
**Post date:** [January 9, 2012, 10:47pm UTC](https://www.ruby-forum.com/t/setting-input-headers-for-an-upstream-server-depending-on-the-requests-path-method/215597/1 "2012-01-09T22:47:40Z")

</div>

Hello, I’m experimenting with having nginx prepare the request to my  
application server in such way I can avoid implementing a router  
there.

In this example, I tried to simulate rails’ restful routes for a blog  
post resource:

[http://pastie.org/3156651](http://pastie.org/3156651)

So if I hit an url like POST /posts, nginx should serve it through the  
upstream app, passing the app parameters like:

more\_set\_input\_headers “X-NS: POSTS” “X-ACTION: create”;

using headers-more module to set input headers. On my app server,  
Instead of parsing the routes, I could just take a look on the headers  
to know who should handle the response.

The configuration on that pastie works but is kind of verbose. Also,  
I’m not sure how well it would work if I had tens or thousands of  
routes (the idea would be to generate the nginx configuration from a  
simpler manifest file, so you could define so called ‘restfull routes’  
without much effort).

Can you think of a better way to do this?

–