# CGI and POST/PUT URL Variables

**URL:** <https://www.ruby-forum.com/t/cgi-and-post-put-url-variables/75071>\
**Category:** Ruby\
**Created:** [November 7, 2006, 11:08am UTC](https://www.ruby-forum.com/t/cgi-and-post-put-url-variables/75071 "2006-11-07T11:08:57Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![Trevor\_Elliott](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/t/8491ac/32.png) [@Trevor\_Elliott](https://www.ruby-forum.com/u/Trevor_Elliott)\
**Post date:** [November 7, 2006, 11:08am UTC](https://www.ruby-forum.com/t/cgi-and-post-put-url-variables/75071/1 "2006-11-07T11:08:57Z")

</div>

Hi Everyone,

I encountered a strange problem when trying to write a cgi script to  
handle a PUT/POST scenario for a set of REST-style web services I’m  
writing in Ruby.

If I do a normal post to a url, say:

/cgi-bin/cgi.rb?a=1&b=1

The params attribute in the CGI class contains {‘a’=\>‘1’, ‘b’=\>‘1’}.  
However, when doing a PUT or POST to the same URL, the params hash  
contains two elements, one that’s empty, and the other that is keyed on  
the payload to the PUT/POST operation.

Can anyone see my error?

Thanks!

-Trevor Elliott

#!/usr/bin/ruby

# 

# CGI script

require ‘cgi’  
require ‘stringio’

cgi = CGI.new  
cgi.out(‘type’ =\> ‘text/plain’) {  
$stderr.write(“handling #{cgi.request\_method} request”)  
cgi.params.inject(StringIO.new) { |out,value|  
value.each { |item| out \<\< 'Item: ’ \<\< item \<\< “\n” }  
out  
}.string  
}

#!/usr/bin/env ruby

# 

# Test script

# uses the ruby-json gem

require ‘net/http’  
require ‘uri’

require ‘rubygems’  
require ‘json/objects’

host = URI.parse(‘[http://127.0.0.1:8080/cgi-bin/cgi.rb?thing=1](http://127.0.0.1:8080/cgi-bin/cgi.rb?thing=1)’)  
req = Net::HTTP::Put.new(host.path + ‘?’ + host.query)  
req.body = {:id =\> 1, :name =\> ‘test’}.to\_json  
req.set\_content\_type(‘text/plain’)  
puts req.body  
puts req.path

res = Net::HTTP.new(host.host, host.port).start { |http|  
http.request(req)  
}  
puts res.body

---

<div class="post-metadata">

**Author:** ![Trevor\_Elliott](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/t/8491ac/32.png) [@Trevor\_Elliott](https://www.ruby-forum.com/u/Trevor_Elliott)\
**Post date:** [November 8, 2006, 12:04pm UTC](https://www.ruby-forum.com/t/cgi-and-post-put-url-variables/75071/2 "2006-11-08T12:04:35Z")

</div>

Trevor Elliott wrote:

> The params attribute in the CGI class contains {‘a’=\>‘1’, ‘b’=\>‘1’}.  
> However, when doing a PUT or POST to the same URL, the params hash  
> contains two elements, one that’s empty, and the other that is keyed on  
> the payload to the PUT/POST operation.
> 
> Can anyone see my error?

There is no error, Ruby’s CGI module ignores the query string when the  
method isn’t GET. AFAIK, this is correct behaviour, you put all query  
parameters into the body of the request when using POST - no idea about  
PUT, that method only sees use with REST, which has been of only passing  
interest to me. [insert rant about HTTP flawedness and bending over  
business logic backwards to be stateless here]

Either redo the client code to use the proper way of passing the query  
string to the application, or redo the CGI script to manually parse the  
request string for the query string. The CGI module should have some  
functionality for that.

Also, see [http://www.w3.org/Provider/Style/URI](http://www.w3.org/Provider/Style/URI) for why “/cgi-bin/” and  
“.rb” are bad, bad things to put in your URL.

David V.

---

<div class="post-metadata">

**Author:** ![Trevor\_Elliott](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/t/8491ac/32.png) [@Trevor\_Elliott](https://www.ruby-forum.com/u/Trevor_Elliott)\
**Post date:** [November 8, 2006, 7:38pm UTC](https://www.ruby-forum.com/t/cgi-and-post-put-url-variables/75071/3 "2006-11-08T19:38:09Z")

</div>

> PUT, that method only sees use with REST, which has been of only passing  
> interest to me. [insert rant about HTTP flawedness and bending over  
> business logic backwards to be stateless here]
> 
> David V.

I had my suspicions after I posted the question, so thanks for  
confirming  
them 🙂 Given that this behavior had worked for me previously in other  
situations, I just expected it to work here; I’ll rethink my interaction  
with the server.

-trevor elliott