Mongrel development - Dec 2007 - Small updates and release plan

Hello Guys,

I''ll like to suggest a small release fix before we start doing big
changes: platform fixes.

Current we''re setting MSWIN32 (mswin32) as platform for Windows gem,
but we should be using Gem::Platform::CURRENT instead (i386-mswin32 as
current Ruby windows implementation).

Also, the jruby/java platform need to be defined. That change will
ease the compatibility path with now launched 0.9.5 version of
rubygems, which currently make our lifes too difficult :-P

I plan to work on this next week and make 0.9.5 install correct
version of prepackaged mongrel gems.
If these changes need to be made on rubygems besides mongrel sides,
I''ll bug Eric Hodel to push forward a small 0.9.5.1 release to solve
this.

I hope it pays me attention (on the contrary of Ryan Davis that just
ignores my patches since september!) :-P

Regards guys and talk later. Nice weekend everybody.

-- 
Luis Lavena
Multimedia systems
-
A common mistake that people make when trying to design
something completely foolproof is to underestimate
the ingenuity of complete fools.
Douglas Adams

Sounds good. I''ve been wanting to do a 1.1.2 release for a while but
haven''t gotten to it.

There''s a change related to return a proxy error code (or something)
that Wayne checked it that needs to be temporarily reverted. It''s too
significant for a point release and it doesn''t have tests right now.

Evan

On Dec 8, 2007 12:57 PM, Luis Lavena <luislavena at gmail.com>
wrote:
> Hello Guys,
>
> I''ll like to suggest a small release fix before we start doing big
> changes: platform fixes.
>
> Current we''re setting MSWIN32 (mswin32) as platform for Windows
gem,
> but we should be using Gem::Platform::CURRENT instead (i386-mswin32 as
> current Ruby windows implementation).
>
> Also, the jruby/java platform need to be defined. That change will
> ease the compatibility path with now launched 0.9.5 version of
> rubygems, which currently make our lifes too difficult :-P
>
> I plan to work on this next week and make 0.9.5 install correct
> version of prepackaged mongrel gems.
> If these changes need to be made on rubygems besides mongrel sides,
> I''ll bug Eric Hodel to push forward a small 0.9.5.1 release to
solve
> this.
>
> I hope it pays me attention (on the contrary of Ryan Davis that just
> ignores my patches since september!) :-P
>
> Regards guys and talk later. Nice weekend everybody.
>
> --
> Luis Lavena
> Multimedia systems
> -
> A common mistake that people make when trying to design
> something completely foolproof is to underestimate
> the ingenuity of complete fools.
> Douglas Adams
> _______________________________________________
> Mongrel-development mailing list
> Mongrel-development at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-development
>


-- 
Evan Weaver
Cloudburst, LLC

On Dec 8, 2007 8:00 PM, Evan Weaver <evan at cloudbur.st>
wrote:
> Sounds good. I''ve been wanting to do a 1.1.2 release for a while
but
> haven''t gotten to it.
>
> There''s a change related to return a proxy error code (or
something)
> that Wayne checked it that needs to be temporarily reverted. It''s
too
> significant for a point release and it doesn''t have tests right
now.
>
I''ll take a look to the new code and maybe create some test for it.
Was the code from a ticket? Maybe that could help me understand better
the idea behind it.

-- 
Luis Lavena
Multimedia systems
-
A common mistake that people make when trying to design
something completely foolproof is to underestimate
the ingenuity of complete fools.
Douglas Adams

That would probably be my patch that I submitted on ticket 15664,

http://rubyforge.org/tracker/index.php?func=detail&aid=15664&group_id=1306&atid=5145

which tries to send a 400 Bad Response in response to a  
HttpParseException.

Cheers

Dave

On 09/12/2007, at 10:26 AM, Luis Lavena wrote:
> On Dec 8, 2007 8:00 PM, Evan Weaver <evan at cloudbur.st> wrote:
>> Sounds good. I''ve been wanting to do a 1.1.2 release for a
while but
>> haven''t gotten to it.
>>
>> There''s a change related to return a proxy error code (or
something)
>> that Wayne checked it that needs to be temporarily reverted.
It''s too
>> significant for a point release and it doesn''t have tests
right now.
>>
>
> I''ll take a look to the new code and maybe create some test for
it.
> Was the code from a ticket? Maybe that could help me understand better
> the idea behind it.
>
> -- 
> Luis Lavena
> Multimedia systems
> -
> A common mistake that people make when trying to design
> something completely foolproof is to underestimate
> the ingenuity of complete fools.
> Douglas Adams
> _______________________________________________
> Mongrel-development mailing list
> Mongrel-development at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-development

On Dec 8, 2007 10:49 PM, Dave Cheney <dave at cheney.net>
wrote:
> That would probably be my patch that I submitted on ticket 15664,
>
>
http://rubyforge.org/tracker/index.php?func=detail&aid=15664&group_id=1306&atid=5145
>
> which tries to send a 400 Bad Response in response to a
> HttpParseException.
>
Thank you Dave, I''ll take a look during the week and maybe came with a
test that stress the issue.

Or, if you already wrote some, please share :-D

Regards and have a nice weekend.

-- 
Luis Lavena
Multimedia systems
-
A common mistake that people make when trying to design
something completely foolproof is to underestimate
the ingenuity of complete fools.
Douglas Adams

On Dec 8, 2007 6:00 PM, Evan Weaver <evan at cloudbur.st> wrote:
> Sounds good. I''ve been wanting to do a 1.1.2 release for a while
but
> haven''t gotten to it.
>
> There''s a change related to return a proxy error code (or
something)
> that Wayne checked it that needs to be temporarily reverted. It''s
too
> significant for a point release and it doesn''t have tests right
now.
>
> Evan
>
If memory serves (and it usually doesn''t)  that change wasn''t
major?

  ~Wayne
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/mongrel-development/attachments/20071209/09924aa5/attachment.html

It''s not a big change in terms of LOC but it will affect how your load
balancer operates, and that seems significant to me.

Evan

On Dec 9, 2007 10:55 PM, Wayne E. Seguin <wayneeseguin at gmail.com>
wrote:
> On Dec 8, 2007 6:00 PM, Evan Weaver <evan at cloudbur.st> wrote:
>
> > Sounds good. I''ve been wanting to do a 1.1.2 release for a
while but
> > haven''t gotten to it.
> >
> > There''s a change related to return a proxy error code (or
something)
> > that Wayne checked it that needs to be temporarily reverted.
It''s too
> > significant for a point release and it doesn''t have tests
right now.
> >
> > Evan
> >
> >
> >
>
> If memory serves (and it usually doesn''t)  that change
wasn''t major?
>
>   ~Wayne
>
> _______________________________________________
> Mongrel-development mailing list
> Mongrel-development at rubyforge.org
> http://rubyforge.org/mailman/listinfo/mongrel-development
>
>


-- 
Evan Weaver
Cloudburst, LLC

Yes - it means using nginx as a proxy to mongrel will actually work !

The current behavior ''stuns'' nginx every time mongrel decides
it
doesn''t like the request as passed (which is fair, nginx isn''t
as
strict in its request parsing as mongrel) causing it to try every  
mongrel in the balancer group in quick succession. The patch makes  
mongrel behave correctly according to the spec and report the correct  
error rather than relying on nginx to pass back a 50x when there are  
no mongrel left.

Cheers

Dave

On 11/12/2007, at 2:56 AM, Evan Weaver wrote:
> It''s not a big change in terms of LOC but it will affect how your
load
> balancer operates, and that seems significant to me.
>
> Evan

On Dec 10, 2007 5:11 PM, Dave Cheney <dave at cheney.net>
wrote:
> Yes - it means using nginx as a proxy to mongrel will actually work !
>
> The current behavior ''stuns'' nginx every time mongrel
decides it
> doesn''t like the request as passed (which is fair, nginx
isn''t as
> strict in its request parsing as mongrel) causing it to try every
> mongrel in the balancer group in quick succession. The patch makes
> mongrel behave correctly according to the spec and report the correct
> error rather than relying on nginx to pass back a 50x when there are
> no mongrel left.
>
So in theory this patch fix the nginx behavior, but how this affects
other balancers like apache one? (I know is broken, but couldn''t miss
the importance).

Based on RFC rules [1], it seems is the correct behavior instead of
the unexpected close of the connection.

Adding some test to the malformed requests doesn''t seem problematic,
but I''ll love some feedback on cross-balancer results (apache,
balancer, delegate, etc).

[1] http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.4

Later,
-- 
Luis Lavena
Multimedia systems
-
A common mistake that people make when trying to design
something completely foolproof is to underestimate
the ingenuity of complete fools.
Douglas Adams

On Dec 10, 2007 3:24 PM, Luis Lavena <luislavena at gmail.com> wrote:
> On Dec 10, 2007 5:11 PM, Dave Cheney <dave at cheney.net> wrote:
> > Yes - it means using nginx as a proxy to mongrel will actually work !
> >
> > The current behavior ''stuns'' nginx every time
mongrel decides it
> > doesn''t like the request as passed (which is fair, nginx
isn''t as
> > strict in its request parsing as mongrel) causing it to try every
> > mongrel in the balancer group in quick succession. The patch makes
> > mongrel behave correctly according to the spec and report the correct
> > error rather than relying on nginx to pass back a 50x when there are
> > no mongrel left.
> >
>
> So in theory this patch fix the nginx behavior, but how this affects
> other balancers like apache one? (I know is broken, but couldn''t
miss
> the importance).
>
> Based on RFC rules [1], it seems is the correct behavior instead of
> the unexpected close of the connection.
>
> Adding some test to the malformed requests doesn''t seem
problematic,
> but I''ll love some feedback on cross-balancer results (apache,
> balancer, delegate, etc).
>
> [1] http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.4
>
Good question, Dave, are you able to test other balancers?

  ~Wayne
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/mongrel-development/attachments/20071210/345249db/attachment.html

On Tue, 11 Dec 2007 07:11:38 +1100
Dave Cheney <dave at cheney.net> wrote:
> Yes - it means using nginx as a proxy to mongrel will actually work !
> 
> The current behavior ''stuns'' nginx every time mongrel
decides it
> doesn''t like the request as passed (which is fair, nginx
isn''t as
> strict in its request parsing as mongrel) causing it to try every  
> mongrel in the balancer group in quick succession. The patch makes  
> mongrel behave correctly according to the spec and report the correct  
> error rather than relying on nginx to pass back a 50x when there are  
> no mongrel left.
Which part of the spec?  ''Cause last time I looked that part of the
spec only applied to a webserver talking to a client.  NOT to a proxy server
which, if written correctly, should try the next server when the one it just
tried dies.

-- 
Zed A. Shaw
- Hate: http://savingtheinternetwithhate.com/
- Good: http://www.zedshaw.com/
- Evil: http://yearofevil.com/

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Mon, 10 Dec 2007, Zed A. Shaw wrote:
> On Tue, 11 Dec 2007 07:11:38 +1100
> Dave Cheney <dave at cheney.net> wrote:
>
>> Yes - it means using nginx as a proxy to mongrel will actually work !
>>
>> The current behavior ''stuns'' nginx every time mongrel
decides it
>> doesn''t like the request as passed (which is fair, nginx
isn''t as
>> strict in its request parsing as mongrel) causing it to try every
>> mongrel in the balancer group in quick succession. The patch makes
>> mongrel behave correctly according to the spec and report the correct
>> error rather than relying on nginx to pass back a 50x when there are
>> no mongrel left.
>
> Which part of the spec?  ''Cause last time I looked that part of
the spec only applied to a webserver talking to a client.  NOT to a proxy server
which, if written correctly, should try the next server when the one it just
tried dies.
Who invited this Zed-guy to the list? He is just spreading FUD around here :)

Anyway, the return code is defined in [1]. you know, it''s not because
your code works right(TM) that all code in the world will work ok
too... and implementing this even clients will display the correct
HTML code.

1. http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.4.1

Cheers,


filipe {
  @             icewall.org
  GPG        1024D/A6BA423E
  Jabber  lautert at jabber.ru
}


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFHXeZimKFbPqa6Qj4RAh2jAJ9GWIb6fJgX3ubHWfnYeQGZn05fBACcDsTH
+7ZuWtyxTc0Pn2bw5HbhuK0=+MNQ
-----END PGP SIGNATURE-----

On Dec 10, 2007 9:52 PM, Zed A. Shaw <zedshaw at zedshaw.com>
wrote:
>
> Which part of the spec?  ''Cause last time I looked that part of
the spec only applied to a webserver talking to a client.  NOT to a proxy server
which, if written correctly, should try the next server when the one it just
tried dies.
>
So we should forward this issue to nginx developers instead to fix
this in your side.

I''ll like to know how apache or ay other proxy/delegator behave under
this circumstance.

And for the record, from the log reported in the ticket, it seems the
client is asking a malformed URL, shouldn''t the proxy take actions
about that?

-- 
Luis Lavena
Multimedia systems
-
A common mistake that people make when trying to design
something completely foolproof is to underestimate
the ingenuity of complete fools.
Douglas Adams

On Dec 10, 2007 10:22 PM, Filipe <filipe at icewall.org>
wrote:
>
> Who invited this Zed-guy to the list? He is just spreading FUD around here
:)
>
Zed was the owner of the circus, we are just pets on the show ;-)
> Anyway, the return code is defined in [1]. you know, it''s not
because
> your code works right(TM) that all code in the world will work ok
> too... and implementing this even clients will display the correct
> HTML code.
>
> 1. http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.4.1
>
A bit above that:

Quote:

10.4 Client Error 4xx

The 4xx class of status code is intended for cases in which the client
seems to have erred. Except when responding to a HEAD request, the
server SHOULD include an entity containing an explanation of the error
situation, and whether it is a temporary or permanent condition. These
status codes are applicable to any request method. User agents SHOULD
display any included entity to the user.

=
As Zed commented, a client, not a proxy.

Quote:

If the client is sending data, a server implementation using TCP
SHOULD be careful to ensure that the client acknowledges receipt of
the packet(s) containing the response, before the server closes the
input connection. If the client continues sending data to the server
after the close, the server''s TCP stack will send a reset packet to
the client, which may erase the client''s unacknowledged input buffers
before they can be read and interpreted by the HTTP application.

==
Again, I''ll *love* to know how apache or any other balancer handle
this edge case.

(with love I mean, more feedback besides nginx) :-D

-- 
Luis Lavena
Multimedia systems
-
A common mistake that people make when trying to design
something completely foolproof is to underestimate
the ingenuity of complete fools.
Douglas Adams

On Mon, 10 Dec 2007 23:22:29 -0200 (BRST)
Filipe <filipe at icewall.org> wrote:

<snip> 
> Anyway, the return code is defined in [1]. you know, it''s not
because
> your code works right(TM) that all code in the world will work ok
> too... and implementing this even clients will display the correct
> HTML code.
> 
> 1. http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.4.1
  10.4.1 400 Bad Request

  The request could not be understood by the server due to malformed
  syntax. The _client_ SHOULD NOT repeat the request without
  modifications. 

Again, this is for "clients" not proxy servers.  The purpose of a
proxy
server is to ensure that a request from a client is serviced by 1 of N
backends.  If a backend closes the connection, that means it''s
malfunctioning in some way, so the proxy server should try another
one.  Clients however should stop talking to a server that does a 400.

Another way to put this is that the HTTP standard doesn''t have anything
that applies to the situation of a load balancing proxy server.  What
you''ll be doing is wasting valuable mongrel time to keep a server happy
that really should understand a closed connection as "try my
neighbor".

-- 
Zed A. Shaw
- Hate: http://savingtheinternetwithhate.com/
- Good: http://www.zedshaw.com/
- Evil: http://yearofevil.com/