From zarlav_net at yahoo.com Wed Feb 1 11:53:44 2012 From: zarlav_net at yahoo.com (=?utf-8?Q?www.zarlav.net__=D0=97=D0=B0=D1=8B=D0=BD_=D1=81=D0=B0=D0=B9=D1=82?=) Date: Wed, 1 Feb 2012 08:53:44 -0800 Subject: =?utf-8?Q?=D0=97=D0=B0=D1=80=D1=8B=D0=BD_=D1=81=D0=B0=D0=B9=D1=82_WWW.ZARLAV.NET?= Message-ID: http://www.zarlav.net ???????? ???????? 40 ????? ?????? ??? ?????? ????????? 1. ????? 40 ??????? ????? ???? ????? ?????? /??????/ 2. ?????? ????? ?????? ???????? ???? /??????/ 3. 10.000 ?????? ?????????? ?????? ?????? /??????/ 4. ????? ??????? ?????? ??????? ????? /??????/ ------------------------------------------- ????? ?? ???????? 275.000 ????????????? ?-??????? ?????? ??????????????? ????????? ?????? ????? ??????? ?????? ?????? ?? ?????? ????? : advertise_mon at yahoo.com From myaskaskk43vasvasin at yahoo.com Fri Feb 3 06:14:27 2012 From: myaskaskk43vasvasin at yahoo.com (Rick) Date: Fri, 3 Feb 2012 19:14:27 +0800 Subject: =?GB2312?B?RGlnaXRhbCBQaG90byBFZGl0aW5nIFNlcnZpY2VzIC0gUGhvdG8gQ3V0b3V0?= Message-ID: You are receiving this email because we wish you to use our digital photo editing services. We are a China based Imaging Professionals. We offer basic and advanced digital photo Editing services and solutions like photo Cutout, morphological photo Editing, photoshop photo Editing, satellite photo Editing, color photo Editing and vector photo Editing using latest techniques. Our mainly services are: 1. Photo Cutout 2. Photo Enhancement 3. Photo Retouching 4. Vector Conversion 5. Pop Art 6. Images Masking 7. Clipping Path 8. Photo Restoration 9. Web Design Looking forward to work for you! Best regards, Rick Toeagrimoit Imaging Professionals Contact: ibwallace at yeah.net Send address to imremove at yeah.net for remove From simasasn8nasgnassn at msn.com Sun Feb 5 04:28:50 2012 From: simasasn8nasgnassn at msn.com (Louis) Date: Sun, 5 Feb 2012 17:28:50 +0800 Subject: Animated Movie/TV Series - Cartoon Movie/TV Series - 3D/2D Animation Services Message-ID: You are receiving this email because we wish you to use our 3D/2D Animated Movie/TV Series Services. We are a China based Animated Movie/TV Series Studio. with the technical, our studio is a animation studio with the technical, creative and production capabilities to create a new generation of animated feature films, merchandise and other related products. Our objective is to combine proprietary technology and world-class creative talent to develop computer-animated feature films with memorable characters and heartwarming stories that appeal to audiences of all ages. We utilize the finest equipment available in the industry, offer efficient data delivery and unrivaled quality and work until the client is fully satisfied with the end product. Core Offerings 2D Animation 3D Animation 4D Animation Cell Animation Cartoon Animation Animated Movies Animated TV Series Architecture Visualization Character Animation Animated Commercial Animated Presentation Walkthrough Animation Flash Presentation Logo Animation Animated Wallpapers Animated Graphics We are also looking for agents who can represent us in USA and Europe in order to gain more Animated Movie orders. Best regards, Louis Fangaganzan Animation Services Contact: ibanicontact at yeah.net Pls send address to anremove at yeah.net for remove -------------------------------------------------------------------------------------------------------------------- MRP es una empresa que se preocupa por la naturaleza. Cada uno de nuestros centros comerciales cuenta con soluciones sustentables, modernas y funcionales que ayudan a conservar el medio ambiente y el ahorro de energ?a. Por lo cual te invitamos a no imprimir este correo. Visita www.mrp.com.mx para mayor informaci?n. From shenamias70yeaiasyan at yahoo.de Sun Feb 26 12:25:05 2012 From: shenamias70yeaiasyan at yahoo.de (Rick) Date: Sun, 26 Feb 2012 20:25:05 +0800 Subject: =?GB2312?B?RGlnaXRhbCBQaG90byBFZGl0aW5nIFNlcnZpY2VzIC0gUGhvdG8gQ3V0b3V0?= Message-ID: <20120226122339.4B5D82AC706@DCUO102.localdomain> You are receiving this email because we wish you to use our digital photo editing services. We are a China based Imaging Professionals. We offer basic and advanced digital photo Editing services and solutions like photo Cutout, morphological photo Editing, photoshop photo Editing, satellite photo Editing, color photo Editing and vector photo Editing using latest techniques. Our mainly services are: 1. Photo Cutout 2. Photo Enhancement 3. Photo Retouching 4. Vector Conversion 5. Pop Art 6. Images Masking 7. Clipping Path 8. Photo Restoration 9. Web Design Looking forward to work for you! Best regards, Rick Toeagrimoit Imaging Professionals Contact: ibwallace at yeah.net Send address to imremove at yeah.net for remove From lunar at anargeek.net Tue Feb 28 22:15:46 2012 From: lunar at anargeek.net (Lunar) Date: Tue, 28 Feb 2012 23:15:46 +0100 Subject: 'Connection reset by peer' when replying before the end of POST data Message-ID: <20120228221546.GC16985@candra> Hi! Short introduction: I am working on a simple "one-click" file sharing web application specific focus on protecting users' privacy?[1]. Thanks to Rainbows! it can work with big uploads without any request buffering which is simply marvelous! :) I am currently trying to implement a limit on the maximum uploaded file size, not unlike what is already done by Rainbows::MaxBody. Unfortunately, it looks like answering a request while the client is in the middle of posting data is not supported that well by Rainbows! Here is a minimal test case: --- 8< --- config.ru --------------------------------------------------- class InterruptTest def call(env) # HTTP 1.1 standard (and curl) needs this /\A100-continue\z/i =~ env['HTTP_EXPECT'] and return [ 100, {}, [] ] error = "Request entity too large!\n" env['rack.input'].read 1000 Rainbows.sleep 1 [ 403, { 'Content-Type' => 'text/plain' }, [ error ] ] end end run InterruptTest.new --- >8 ----------------------------------------------------------------- --- 8< --- rainbows.conf ----------------------------------------------- Rainbows! do use :ThreadSpawn rewindable_input false client_max_body_size nil end --- >8 ----------------------------------------------------------------- I am starting Rainbows! with the following command-line: $ rainbows -E none -p 8081 -c rainbows.conf rackup.ru And then, when asking curl (the `test` file is 7636 bytes long): $ curl -v -F "file=@test;type=text/plain" http://localhost:8081 * About to connect() to localhost port 8081 (#0) * Trying 127.0.0.1... connected * Connected to localhost (127.0.0.1) port 8081 (#0) > POST / HTTP/1.1 > User-Agent: curl/7.21.0 (i486-pc-linux-gnu) libcurl/7.21.0 > OpenSSL/0.9.8o zlib/1.2.3.4 libidn/1.15 libssh2/1.2.6 > Host: localhost:8081 > Accept: */* > Content-Length: 7829 > Expect: 100-continue > Content-Type: multipart/form-data; > boundary=----------------------------cd790f73307f > < HTTP/1.1 100 Continue < HTTP/1.1 403 Forbidden < Date: Tue, 28 Feb 2012 21:20:15 GMT < Status: 403 Forbidden < Connection: close < Content-Type: text/plain < Request entity too large! * Recv failure: Connection reset by peer * Closing connection #0 curl: (56) Recv failure: Connection reset by peer This "connection reset by peer" is annoying as it will result in Apache stating "Bad gateway", or Firefox displaying "The connection was reset". I believe Rainbows::MaxBody having the same issue, but I am not sure. Also looking at the code, it looks like Rainbows::MaxBody trust the Content-Length header and do not mesure the actual amount of bytes received if the header is present. I believe Content-Length can be faked by malicious clients, so it might be better to use limit_input! for every connections. In any cases, I would very much like to solve this issue, but I feel a little bit lost on where to start. My assumption was that other webservers were doing it right, otherwise no one would ever see a 413 Request Entity Too Large message in a browser. I see that Nginx has options related to SO_LINGER and that Apache also mention "Lingering Close" when discussing how to close connections. But I don't really know where to poke on Rainbows! to play with these kinds of options. Anyway, this issue looks closeloy like the one described in section 8 of . Thanks again for any help solving this. :) [1]?You can have a look at , but there is not that much to see yet. The code using Rainbows! is not yet in a releasable state, but progress is steady, so expect some news later. :) [2] Cheers, -- Lunar From normalperson at yhbt.net Tue Feb 28 23:39:19 2012 From: normalperson at yhbt.net (Eric Wong) Date: Tue, 28 Feb 2012 23:39:19 +0000 Subject: 'Connection reset by peer' when replying before the end of POST data In-Reply-To: <20120228221546.GC16985@candra> References: <20120228221546.GC16985@candra> Message-ID: <20120228233919.GA10168@dcvr.yhbt.net> Lunar wrote: > Hi! > > Short introduction: I am working on a simple "one-click" file > sharing web application specific focus on protecting users' privacy?[1]. > Thanks to Rainbows! it can work with big uploads without any request > buffering which is simply marvelous! :) Good to know, I also handle a lot of uploads (via PUT, though) > I am currently trying to implement a limit on the maximum uploaded file > size, not unlike what is already done by Rainbows::MaxBody. > Unfortunately, it looks like answering a request while the client is in > the middle of posting data is not supported that well by Rainbows! Rainbows! really can't be "nice" to clients that try to abuse it. > Here is a minimal test case: > > --- 8< --- config.ru --------------------------------------------------- > > class InterruptTest > def call(env) > # HTTP 1.1 standard (and curl) needs this If you get a Content-Length, you can return something other than 100 if Content-Length is too much. > /\A100-continue\z/i =~ env['HTTP_EXPECT'] and return [ 100, {}, [] ] > error = "Request entity too large!\n" > env['rack.input'].read 1000 You can also drain the socket to avoid connection resets: input = env['rack.input'] buf = "" # reuse buf to reduce GC pressure while input.read(1024, buf) # ignore buf, keep reading until nil end > Rainbows.sleep 1 > [ 403, { 'Content-Type' => 'text/plain' }, [ error ] ] > end > end > > run InterruptTest.new > > --- >8 ----------------------------------------------------------------- > > --- 8< --- rainbows.conf ----------------------------------------------- > > Rainbows! do > use :ThreadSpawn > rewindable_input false > client_max_body_size nil > end > > --- >8 ----------------------------------------------------------------- > > I am starting Rainbows! with the following command-line: > > $ rainbows -E none -p 8081 -c rainbows.conf rackup.ru > > And then, when asking curl (the `test` file is 7636 bytes long): > > $ curl -v -F "file=@test;type=text/plain" http://localhost:8081 > * About to connect() to localhost port 8081 (#0) > * Trying 127.0.0.1... connected > * Connected to localhost (127.0.0.1) port 8081 (#0) > > POST / HTTP/1.1 > > User-Agent: curl/7.21.0 (i486-pc-linux-gnu) libcurl/7.21.0 > > OpenSSL/0.9.8o zlib/1.2.3.4 libidn/1.15 libssh2/1.2.6 > > Host: localhost:8081 > > Accept: */* > > Content-Length: 7829 > > Expect: 100-continue > > Content-Type: multipart/form-data; > > boundary=----------------------------cd790f73307f > > > < HTTP/1.1 100 Continue > < HTTP/1.1 403 Forbidden > < Date: Tue, 28 Feb 2012 21:20:15 GMT > < Status: 403 Forbidden > < Connection: close > < Content-Type: text/plain > < > Request entity too large! > * Recv failure: Connection reset by peer > * Closing connection #0 > curl: (56) Recv failure: Connection reset by peer > > This "connection reset by peer" is annoying as it will result in Apache > stating "Bad gateway", or Firefox displaying "The connection was reset". > I believe Rainbows::MaxBody having the same issue, but I am not sure. Yes MaxBody does have this issue. It's better to save bandwidth than show a nice error message if somebody is trying to attack you. But you can implement the socket draining example above to get the nice error message. > Also looking at the code, it looks like Rainbows::MaxBody trust the > Content-Length header and do not mesure the actual amount of bytes > received if the header is present. I believe Content-Length can be faked > by malicious clients, so it might be better to use limit_input! for > every connections. It only uses Content-Length as a hint. Unicorn::StreamInput (the env["rack.input"] object) won't read _past_ Content-Length so HTTP pipelining can be used with uploads. If it reads too little, then it'll just timeout eventually. > In any cases, I would very much like to solve this issue, but I feel a > little bit lost on where to start. > > My assumption was that other webservers were doing it right, otherwise > no one would ever see a 413 Request Entity Too Large message in a > browser. They probably drain the socket or wait a bit before closing the connection. Rack doesn't give developers much control over how the socket is managed. > I see that Nginx has options related to SO_LINGER and that > Apache also mention "Lingering Close" when discussing how to close > connections. But I don't really know where to poke on Rainbows! to play > with these kinds of options. Anyway, this issue looks closeloy like the > one described in section 8 of > . Also, neither Matz Ruby 1.8 nor 1.9 can do lingering close as IO#close still holds onto the GVL (blocking all clients). I tried to make close(2) release the GVL for 1.9.3, but it doesn't interact well if another thread was operating on that IO object. > Thanks again for any help solving this. :) > > [1]?You can have a look at > , but there is not > that much to see yet. The code using Rainbows! is not yet in a > releasable state, but progress is steady, so expect some news > later. :) Cool (especially that you host your own), I don't see an obvious way to clone your repo and look at it, though :x From lunar at anargeek.net Wed Feb 29 07:22:34 2012 From: lunar at anargeek.net (Lunar) Date: Wed, 29 Feb 2012 08:22:34 +0100 Subject: 'Connection reset by peer' when replying before the end of POST data In-Reply-To: <20120228233919.GA10168@dcvr.yhbt.net> References: <20120228221546.GC16985@candra> <20120228233919.GA10168@dcvr.yhbt.net> Message-ID: <20120229072234.GB9007@candra> Hi Eric, Thanks for your quick answer! Eric Wong wrote: > Lunar wrote: > > I am currently trying to implement a limit on the maximum uploaded file > > size, not unlike what is already done by Rainbows::MaxBody. > > Unfortunately, it looks like answering a request while the client is in > > the middle of posting data is not supported that well by Rainbows! > [...] > > You can also drain the socket to avoid connection resets: > > input = env['rack.input'] > buf = "" # reuse buf to reduce GC pressure > while input.read(1024, buf) > # ignore buf, keep reading until nil > end I thought about it, but I would rather not do that. Coquelicot is meant as a small, self-contained application that can also be run at home behind broadband connections with small bandwidth or quota. If users set a file limit of 5 MiB, I would rather not drain the whole 700 MiB before denying the request. > > In any cases, I would very much like to solve this issue, but I feel a > > little bit lost on where to start. > > > > My assumption was that other webservers were doing it right, otherwise > > no one would ever see a 413 Request Entity Too Large message in a > > browser. > > They probably drain the socket or wait a bit before closing the > connection. Rack doesn't give developers much control over how the > socket is managed. Quoting the "HTTP Connection Management" document?[1] which I mentioned previously: "Servers must therefore close each half of the connection independently." After digging some more at Nginx, it looks like Nginx is doing exactly that. I also looked at Apache and the code responsible for half-closing both side of the connection is very readable. Function is called `ap_lingering_close()` in server/connection.c. It looks like there is no way to call shutdown(2) in Ruby 1.8.7, but from the documentation, Ruby 1.9.3 has IO#close_read and IO#close_write method that will call shutdown(2) for each half of a socket. I don't have Ruby 1.9.3 right now, but I can try to produce a test case later demonstrating the differences between calling `@io.close` and `@io.close_write; @io.close`. In any case, I think it would worth to try to add such call sequences in Rainbows! and see if it helps. If you can't give it a shot yourself, could you point me to the relevant part of the code? [1]? > Also, neither Matz Ruby 1.8 nor 1.9 can do lingering close as IO#close > still holds onto the GVL (blocking all clients). > > I tried to make close(2) release the GVL for 1.9.3, but it doesn't > interact well if another thread was operating on that IO object. I am not that versed in Ruby internal, but I fail to see how this could be related to first closing the clients write side of the connection. There should be a window between IO#close_write and IO#close in which in GVL does not matter, does it? > > [1]?You can have a look at > > , but there is not > > that much to see yet. The code using Rainbows! is not yet in a > > releasable state, but progress is steady, so expect some news > > later. :) > > Cool (especially that you host your own), I don't see an obvious way to > clone your repo and look at it, though :x I will keep the list in touch when interesting meat is available. In the meantime, you should be able to `git://git.codecoop.org/coquelicot.git` (maybe in a few hours, it looks the public access got lost at some point). Cheers, -- Lunar From normalperson at yhbt.net Wed Feb 29 17:23:15 2012 From: normalperson at yhbt.net (Eric Wong) Date: Wed, 29 Feb 2012 17:23:15 +0000 Subject: 'Connection reset by peer' when replying before the end of POST data In-Reply-To: <20120229072234.GB9007@candra> References: <20120228221546.GC16985@candra> <20120228233919.GA10168@dcvr.yhbt.net> <20120229072234.GB9007@candra> Message-ID: <20120229172315.GA26630@dcvr.yhbt.net> Lunar wrote: > Quoting the "HTTP Connection Management" document?[1] which I mentioned > previously: "Servers must therefore close each half of the connection > independently." > > After digging some more at Nginx, it looks like Nginx is doing exactly > that. I also looked at Apache and the code responsible for half-closing > both side of the connection is very readable. Function is called > `ap_lingering_close()` in server/connection.c. It's very expensive to do what Apache does with threads+Rainbows!. It also appears that Apache and nginx continues to completely drain the socket if the client is sending, too (which is your case). I don't know if there's a way around draining the socket entirely to avoid connection resets in the client :< I'm more interested in keeping good clients going and not wasting server resources dealing with clients I don't want in the first place. > It looks like there is no way to call shutdown(2) in Ruby 1.8.7, but > from the documentation, Ruby 1.9.3 has IO#close_read and IO#close_write > method that will call shutdown(2) for each half of a socket. There's a shutdown method in BasicSocket for 1.8 > In any case, I think it would worth to try to add such call sequences in > Rainbows! and see if it helps. If you can't give it a shot yourself, > could you point me to the relevant part of the code? You could emulate lingering close with something like this: (valid for ThreadSpawn/ThreadPool, not EM/Cool.io stuff) diff --git a/lib/rainbows/client.rb b/lib/rainbows/client.rb index b456eca..9d8256a 100644 --- a/lib/rainbows/client.rb +++ b/lib/rainbows/client.rb @@ -6,4 +6,16 @@ class Rainbows::Client < Kgio::Socket include Rainbows::ProcessClient alias write kgio_write + + def close + close_write + buf = "" + begin + kgio_wait_readable(2) + buf = kgio_tryread(512, buf) + rescue + break + end while buf + super + end end I'm not going to apply that to Rainbows!, it's needless overhead/complexity for dealing with clients I want to reject anyways (and you're still draining the client socket). > [1]? > > > Also, neither Matz Ruby 1.8 nor 1.9 can do lingering close as IO#close > > still holds onto the GVL (blocking all clients). > > > > I tried to make close(2) release the GVL for 1.9.3, but it doesn't > > interact well if another thread was operating on that IO object. > > I am not that versed in Ruby internal, but I fail to see how this could > be related to first closing the clients write side of the connection. > There should be a window between IO#close_write and IO#close in which in > GVL does not matter, does it? Having the kernel handle lingering close() should be an "easier" version of the above patch (but I think you still need to drain the input as long as your client is sending). From lunar at anargeek.net Wed Feb 29 20:57:58 2012 From: lunar at anargeek.net (Lunar) Date: Wed, 29 Feb 2012 21:57:58 +0100 Subject: 'Connection reset by peer' when replying before the end of POST data In-Reply-To: <20120229172315.GA26630@dcvr.yhbt.net> References: <20120228221546.GC16985@candra> <20120228233919.GA10168@dcvr.yhbt.net> <20120229072234.GB9007@candra> <20120229172315.GA26630@dcvr.yhbt.net> Message-ID: <20120229205758.GB10775@candra> Eric Wong wrote: > Lunar wrote: > > Quoting the "HTTP Connection Management" document?[1] which I mentioned > > previously: "Servers must therefore close each half of the connection > > independently." > > > > After digging some more at Nginx, it looks like Nginx is doing exactly > > that. I also looked at Apache and the code responsible for half-closing > > both side of the connection is very readable. Function is called > > `ap_lingering_close()` in server/connection.c. > > It's very expensive to do what Apache does with threads+Rainbows!. It > also appears that Apache and nginx continues to completely drain the > socket if the client is sending, too (which is your case). > > I don't know if there's a way around draining the socket entirely to > avoid connection resets in the client :< With your proposed patch, everything is working as intended. At least, I can confirm Firefox correctly display the error message sent by the server and not the less understandable "Connection reset by peer". I can also confirm that it does not send the complete file: it looks like it stops sending as soon as either it notices the socket is closed on its write part, or when the response arrives. I am satisfied enough not to dive in libxpcom? > You could emulate lingering close with something like this: > (valid for ThreadSpawn/ThreadPool, not EM/Cool.io stuff) > > diff --git a/lib/rainbows/client.rb b/lib/rainbows/client.rb > index b456eca..9d8256a 100644 > --- a/lib/rainbows/client.rb > +++ b/lib/rainbows/client.rb > @@ -6,4 +6,16 @@ class Rainbows::Client < Kgio::Socket > include Rainbows::ProcessClient > > alias write kgio_write > + > + def close > + close_write > + buf = "" > + begin > + kgio_wait_readable(2) > + buf = kgio_tryread(512, buf) > + rescue > + break > + end while buf > + super > + end > end > > I'm not going to apply that to Rainbows!, it's needless > overhead/complexity for dealing with clients I want to reject > anyways (and you're still draining the client socket). That was exactly what I was looking for. It even works fine on Ruby 1.8.7. I can include that code directly in Coquelicot (by reopening Rainbows::Client to add this extra method) so my pet case is solved. I could see it part of Rainbows!, as optional behaviour, off by default if you'd prefer, but I am fine either way. Thanks for your help! I will let you know as soon as enhanced Coquelicot codebase using Rainbows! is clean enough for a wider exposure (and I have been noticed that the public repository is now back). Cheers, -- Lunar From normalperson at yhbt.net Wed Feb 29 21:36:01 2012 From: normalperson at yhbt.net (Eric Wong) Date: Wed, 29 Feb 2012 21:36:01 +0000 Subject: 'Connection reset by peer' when replying before the end of POST data In-Reply-To: <20120229205758.GB10775@candra> References: <20120228221546.GC16985@candra> <20120228233919.GA10168@dcvr.yhbt.net> <20120229072234.GB9007@candra> <20120229172315.GA26630@dcvr.yhbt.net> <20120229205758.GB10775@candra> Message-ID: <20120229213601.GA7116@dcvr.yhbt.net> Lunar wrote: > With your proposed patch, everything is working as intended. At least, I > can confirm Firefox correctly display the error message sent by the > server and not the less understandable "Connection reset by peer". I can > also confirm that it does not send the complete file: it looks like it > stops sending as soon as either it notices the socket is closed on its > write part, or when the response arrives. I am satisfied enough not to > dive in libxpcom? Cool, thanks for confirming. It's good that your client knows to back off. My original patch isn't safe for bad clients that send continously. Below is a safer version of my original patch, can you see if it works? diff --git a/lib/rainbows/client.rb b/lib/rainbows/client.rb index b456eca..1dcb6d4 100644 --- a/lib/rainbows/client.rb +++ b/lib/rainbows/client.rb @@ -6,4 +6,16 @@ class Rainbows::Client < Kgio::Socket include Rainbows::ProcessClient alias write kgio_write + + def close + close_write + kgio_wait_readable(2) + buf = "" + case kgio_tryread(512, buf) + when nil, Symbol + break + end while true + ensure + super + end end > I could see it part of Rainbows!, as optional behaviour, off by default > if you'd prefer, but I am fine either way. I'll probably call it "lingering_close" like nginx calls it. Of course this needs to be supported for EM/Cool.io, too.