Subject:
|
Re: POST vs. GET (was: Re: IGNORE: yet another test message)
|
Newsgroups:
|
lugnet.admin.general
|
Date:
|
Thu, 6 Apr 2000 01:31:07 GMT
|
Highlighted:
|
!
(details)
|
Viewed:
|
614 times
|
| |
|
|
In lugnet.admin.general, Matthew Miller writes:
> Todd Lehman <lehman@javanet.com> wrote:
> > HTTP GET isn't part of the API for that CGI script (only HTTP POST is part
> > of the defined API). I just added a thingy to reject GET requests. (You
> > still needed your member sign-in cookie with the GET, of course.) GETs are
> > undesirable in this case because the raw data winds up in the httpd logs.
>
> Sorry. I was just playing. (A lot easier to make a URL pointing to a get
> request. *grin*)
Have a look at HTTP::Request::Common... If you have a file of spooled-up
outgoing ratings to submit periodically, i.e.
lugnet.foo.bar 70
lugnet.bar.foo 40
lugnet.glorp.gnort 80
etc.
and you slurp it into a scalar variable $ratings, then you can make a POST
request pretty easily with:
use HTTP::Request::Common;
my @keyval = map { "RATE~" . $_->[0], $_->[1] }
map { [ split /\s+/ ] }
split /\n/, $ratings;
my $req = HTTP::Request::Common::POST(
"http://www.lugnet.com/news/rate.cgi",
\@keyval);
And you can do
print $req->as_string, "\n";
to see the request prior to submitting it, if that's helpful.
HTTP::Cookies makes setting the cookie very easy.
> I tried to search for it (found to docs on avid.cgi, btw) with no luck.
I musta lost it before posting it. While typing it up, I realized something
about that design that I didn't like, so I changed that part in the code,
which caused most of my message to be moot, and I musta nuked it. I'll
cobble something new together.
> It would be very nice to have an script that works in a way opposite to
> rate.cgi -- i.e., takes a lugnet.newsgroup:#### and returns the rating data.
> (avid.cgi seems awfully inconvenient for this purpose.)
Dang, I think the message I nuked also had some ideas in it about this. What
I want to provide ultimately is a thing where a client can say, "Show me all
the new ratings since some epoch time, and the server would spit back a list
of all changepoints that occurred on or after that timestamp. Then it would
also include a timestamp at the end, so the client new what timestamp to pass
the next time. This would be better for both the client and the server than
having the client poll individual messages for new ratings periodically (which
would be very bad).
--Todd
|
|
Message has 1 Reply:
Message is in Reply To:
29 Messages in This Thread:
  
 
- Entire Thread on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
This Message and its Replies on One Page:
- Nested:
All | Brief | Compact | Dots
Linear:
All | Brief | Compact
|
|
|
|
