On Mon, 2007-04-30 at 17:36 +0200, Steve Schnepp wrote:[...]

The fact that you treat GET and POST differently is really an
application decision - there's nothing at the HTTP level that would
support that view. As such I think we should leave that to the
application, rather than making it part of an HTTP proxy.

Additional views anyone?[...]

On Mon, 2007-04-30 at 18:59 +0200, Lee Jin wrote:[...]

There is nothing special about these messages - they are just problems
in delivering the response to the clients, usually because the client
clicked "stop" or exited the browser prematurely. The timeouts may be
caused by network congestion somewhere between Pound and the client (not
necessarily on your machine - it could be anywhere on the way), but you
could increase the Client value to prevent most of them from occurring.[...]

Robert Segall wrote:[...][...]
>>> not much help, as a simple GET or POST may include parameters.
Care to
>>> expand on this?[...][...]

The original intent was that GET be r/o and POST be r/w; application
developers muddied the waters early on because some browsers didn't
support POST. REST has pushed developers back to the original intent of
the HTTP verbs.

Aside: some applications were vulnerable to some serious issues due to
conflating GET and POST. At least one version of the Blackboard learning
management system allowed GET calls to delete information so when a
logged-in user ran a spider against the site to find broken pages, the
spider dutifully told Blackboard to delete all the content and
Blackboard helpfully complied. Not a security problem per se, but
definitely a problem that would've been avoided had the original intent
of the spec been followed...

hth,
[...]

Robert,

what would we need to upgrade?  I'm guessing the thread library, what is 
your recommendation for Redhat linux?
[...]
>>> You don't say on which system Pound runs, which is important.
Pound is
>>> only as good as the underlying threads library. If the library is
not
>>> quite up to par then Pound performance will suffer.
>>>
>>> This sort of problem occurs quite often on older Linux systems
(kernel
>>> 2.4 or earlier, and some RedHat versions) and on some BSD systems
>>> (user-space threads). There is no easy cure except an upgrade.
>>>   
>>>       [...][...]

> The fact that you treat GET and POST differently is really an[...]

Yes, the HTTP standard strongly suggests otherwise. See RFC 2616.

http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html

"In particular, the convention has been established that the GET and
HEAD methods SHOULD NOT have the significance of taking an action
other than retrieval. These methods ought to be considered "safe".
This allows user agents to represent other methods, such as POST, PUT
and DELETE, in a special way, so that the user is made aware of the
fact that a possibly unsafe action is being requested."

-D

I have a monitoring service which also reports this, it polls every hour 
to see if http is alive. This happens on any load:

Worst result recorded:

      gemiddelde reactietijd : 0,519 seconde (average response time)
      kleinste reactietijd : 0,041 seconde (smallest response time)
      grootste reactietijd : 14,176 seconden (greatest response time)

Last result:

      gemiddelde reactietijd : 0,187 seconde (average)
      kleinste reactietijd : 0,038 seconde (smallest)
      grootste reactietijd : 4,172 seconden (greatest)

(I think 4 seconds is still alot, internet users already give a weird 
look if stuff doesn't come rolling in immediatly).

One question: does pound start forwarding the http response once the 
full response from the backend is received (store-and-forward) or does 
it start forwarding the response immediatly (cut-through)?

Glenn


Khaled Hassounah wrote:[...]