[#32009] merging nokogiri to ext/ — Aaron Patterson <aaron@...>

I would like to merge nokogiri to ext for the 1.9.3 release. I spoke to

82 messages 2010/09/02
[#32010] Re: merging nokogiri to ext/ — "U.Nakamura" <usa@...> 2010/09/02

Hello,

[#32012] Re: merging nokogiri to ext/ — Ryan Davis <ryand-ruby@...> 2010/09/02

[#32030] Re: merging nokogiri to ext/ — "NARUSE, Yui" <naruse@...> 2010/09/03

Hi,

[#32033] Re: merging nokogiri to ext/ — "NARUSE, Yui" <naruse@...> 2010/09/03

2010/9/3 NARUSE, Yui <naruse@airemix.jp>:

[#32155] Re: merging nokogiri to ext/ — Yusuke ENDOH <mame@...> 2010/09/08

Currently, we're discussing three different topics:

[#32189] Re: merging nokogiri to ext/ — Aaron Patterson <aaron@...> 2010/09/09

On Thu, Sep 09, 2010 at 01:40:34AM +0900, Yusuke ENDOH wrote:

[#32056] [Ruby 1.8-Bug#3788][Open] URI cannot parse IPv6 addresses propertly — Adam Majer <redmine@...>

Bug #3788: URI cannot parse IPv6 addresses propertly

16 messages 2010/09/04

[#32110] Ruby 2.0 Wiki/Wish-list? — Joshua Ballanco <jballanc@...>

Hi all,

41 messages 2010/09/07
[#32114] Re: Ruby 2.0 Wiki/Wish-list? — "NARUSE, Yui" <naruse@...> 2010/09/08

2010/9/8 Joshua Ballanco <jballanc@gmail.com>:

[#32117] Re: Ruby 2.0 Wiki/Wish-list? — Joshua Ballanco <jballanc@...> 2010/09/08

On Sep 7, 2010, at 5:21 PM, NARUSE, Yui wrote:

[#32143] Re: Ruby 2.0 Wiki/Wish-list? — Roger Pack <rogerdpack2@...> 2010/09/08

> So, for example, a few things I've wanted for a long time:

[#32135] [Ruby-Bug#3802][Open] freeaddrinfo not found in WS2_32.dll — Thomas Volkmar Worm <redmine@...>

Bug #3802: freeaddrinfo not found in WS2_32.dll

16 messages 2010/09/08

[#32154] Making custom_lambda() work — Magnus Holm <judofyr@...>

A tiny suggestion for how we could make it possible to call lambdas

15 messages 2010/09/08
[#32159] Re: Making custom_lambda() work — Nikolai Weibull <now@...> 2010/09/08

On Wed, Sep 8, 2010 at 18:21, Magnus Holm <judofyr@gmail.com> wrote:

[#32156] Can we convert the standard library to gems? — James Edward Gray II <james@...>

Taken from the bundle Nokogiri thread:

98 messages 2010/09/08
[#32161] Re: Can we convert the standard library to gems? — Marcus Rueckert <darix@...> 2010/09/08

On 2010-09-09 01:45:43 +0900, James Edward Gray II wrote:

[#32166] Re: Can we convert the standard library to gems? — James Edward Gray II <james@...> 2010/09/08

On Sep 8, 2010, at 12:03 PM, Marcus Rueckert wrote:

[#32173] Re: Can we convert the standard library to gems? — Marcus Rueckert <darix@...> 2010/09/08

On 2010-09-09 02:54:26 +0900, James Edward Gray II wrote:

[#32249] Re: Can we convert the standard library to gems? — Aaron Patterson <aaron@...> 2010/09/09

On Thu, Sep 09, 2010 at 05:26:54AM +0900, Marcus Rueckert wrote:

[#32278] Re: Can we convert the standard library to gems? — Lucas Nussbaum <lucas@...> 2010/09/10

On 10/09/10 at 02:41 +0900, Aaron Patterson wrote:

[#32162] Re: Can we convert the standard library to gems? — Yusuke ENDOH <mame@...> 2010/09/08

Hi,

[#32216] Re: Can we convert the standard library to gems? — Ryan Davis <ryand-ruby@...> 2010/09/09

[#32229] Re: Can we convert the standard library to gems? — Yusuke ENDOH <mame@...> 2010/09/09

Hi,

[#32260] Re: Can we convert the standard library to gems? — Ryan Davis <ryand-ruby@...> 2010/09/09

[#32275] Re: Can we convert the standard library to gems? — Urabe Shyouhei <shyouhei@...> 2010/09/10

I'm off today so sorry if I missed some mails.

[#32293] Re: Can we convert the standard library to gems? — James Cox <james@...> 2010/09/10

Urabe,

[#32316] Re: Can we convert the standard library to gems? — Urabe Shyouhei <shyouhei@...> 2010/09/11

(2010/09/10 23:48), James Cox wrote:

[#32322] Re: Can we convert the standard library to gems? — James Tucker <jftucker@...> 2010/09/11

[#32335] Re: Can we convert the standard library to gems? — Urabe Shyouhei <shyouhei@...> 2010/09/12

I'm at an airport back to my home so in short,

[#32343] Re: Can we convert the standard library to gems? — James Cox <james@...> 2010/09/12

On Sun, Sep 12, 2010 at 6:51 AM, Urabe Shyouhei <shyouhei@ruby-lang.org> wrote:

[#32382] Re: Can we convert the standard library to gems? — Urabe Shyouhei <shyouhei@...> 2010/09/14

(2010/09/13 3:54), James Cox wrote:

[#32383] Re: Can we convert the standard library to gems? — James Cox <james@...> 2010/09/14

On Tue, Sep 14, 2010 at 12:37 PM, Urabe Shyouhei <shyouhei@ruby-lang.org> wrote:

[#32393] Re: Can we convert the standard library to gems? — Urabe Shyouhei <shyouhei@...> 2010/09/15

How difficult to make myself understood in English.

[#32396] Re: Can we convert the standard library to gems? — James Cox <james@...> 2010/09/15

On Wed, Sep 15, 2010 at 1:43 AM, Urabe Shyouhei <shyouhei@ruby-lang.org> wrote:

[#32399] Re: Can we convert the standard library to gems? — Yusuke ENDOH <mame@...> 2010/09/15

Hi,

[#32400] Re: Can we convert the standard library to gems? — James Cox <james@...> 2010/09/15

On Wed, Sep 15, 2010 at 12:07 PM, Yusuke ENDOH <mame@tsg.ne.jp> wrote:

[#32401] Re: Can we convert the standard library to gems? — Marcus Rueckert <darix@...> 2010/09/15

On 2010-09-16 01:42:39 +0900, James Cox wrote:

[#32402] Re: Can we convert the standard library to gems? — James Cox <james@...> 2010/09/15

On Wed, Sep 15, 2010 at 1:35 PM, Marcus Rueckert <darix@opensu.se> wrote:

[#32411] Re: Can we convert the standard library to gems? — Marcus Rueckert <darix@...> 2010/09/15

On 2010-09-16 03:36:56 +0900, James Cox wrote:

[#32412] Re: Can we convert the standard library to gems? — James Cox <james@...> 2010/09/16

On Wednesday, September 15, 2010, Marcus Rueckert <darix@opensu.se> wrote:

[#32414] Re: Can we convert the standard library to gems? — Lucas Nussbaum <lucas@...> 2010/09/16

On 16/09/10 at 11:02 +0900, James Cox wrote:

[#32248] Replacing stdlib Date with C version — Jeremy Evans <code@...>

I've recently been working on a replacement for the stdlib Date class,

15 messages 2010/09/09

[#32290] [Ruby 1.9.2-Backport#3818][Open] Seg fault with ruby tmail and ruby 1.9.2 — Karl Baum <redmine@...>

Backport #3818: Seg fault with ruby tmail and ruby 1.9.2

10 messages 2010/09/10

[#32453] Why doesn’t Enumerable define a #last method? — Nikolai Weibull <now@...>

Hi!

9 messages 2010/09/17

[#32454] [Ruby 1.9-Feature#3845][Open] "in" infix operator — Yusuke Endoh <redmine@...>

Feature #3845: "in" infix operator

20 messages 2010/09/17
[#32489] Re: [Ruby 1.9-Feature#3845][Open] "in" infix operator — Benoit Daloze <eregontp@...> 2010/09/21

On 17 September 2010 12:30, Yusuke Endoh <redmine@ruby-lang.org> wrote:

[#32529] [Ruby 1.9-Bug#3869][Open] Logger#log does not handle or escape new-line characters. — Hal Brodigan <redmine@...>

Bug #3869: Logger#log does not handle or escape new-line characters.

9 messages 2010/09/23

[#32585] Proposal for Optional Static Typing for Ruby — Martin Pilkington <pilky@...>

Hi,

47 messages 2010/09/27
[#32588] Re: Proposal for Optional Static Typing for Ruby — Yukihiro Matsumoto <matz@...> 2010/09/27

Hi,

[#32592] Re: Proposal for Optional Static Typing for Ruby — Martin Pilkington <pilky@...> 2010/09/28

Hi Matz

[#32595] Re: Proposal for Optional Static Typing for Ruby — Asher <asher@...> 2010/09/28

Martin,

[#32611] Re: Proposal for Optional Static Typing for Ruby — Loren Segal <lsegal@...> 2010/09/28

Hi,

[#32628] Re: Proposal for Optional Static Typing for Ruby — Eleanor McHugh <eleanor@...> 2010/09/29

It strikes me that much of the premise behind this thread is misguided as it overlooks the importance of meta-programming in developing any Ruby program of substantive size. Where a Java or C++ programmer might write a factory method to create instances of a class and spend much of their effort enumerating types explicitly, it's not unusual in Ruby to write meta-programs which create a variety of class and method definitions on request to create or repurpose object instances for the task at hand.

[#32634] [Ruby 1.9-Bug#3889][Open] Incorrectly detected i686-w64-mingw32 as x64-mingw — Luis Lavena <redmine@...>

Bug #3889: Incorrectly detected i686-w64-mingw32 as x64-mingw

21 messages 2010/09/29

[ruby-core:32407] [Ruby-Bug#3835][Open] Resolv::DNS: Retry via TCP on truncated UDP response

From: Julian Mehnle <redmine@...>
Date: 2010-09-15 20:48:33 UTC
List: ruby-core #32407
Bug #3835: Resolv::DNS: Retry via TCP on truncated UDP response
http://redmine.ruby-lang.org/issues/show/3835

Author: Julian Mehnle
Status: Open, Priority: Normal
Category: lib
ruby -v: ruby 1.9.2p0 (2010-08-18 revision 29036) [x86_64-linux]

Resolv::DNS has code implementing DNS queries via TCP, but it is not currently used at all.  Furthermore, any truncated responses received via UDP are parsed and intact RRs are used, silently discarding any truncated RRs.  E.g.:

    $ dig amazon.com TXT
    ;; Truncated, retrying in TCP mode.

    ; <<>> DiG 9.6.1-P3 <<>> amazon.com TXT
    ;; global options: +cmd
    ;; Got answer:
    ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 1197
    ;; flags: qr rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 0

    ;; QUESTION SECTION:
    ;amazon.com.                    IN      TXT

    ;; ANSWER SECTION:
    amazon.com.             3592    IN      TXT     "spf2.0/pra ip4:207.171.160.0/19 ip4:87.238.80.0/21 ip4:72.21.193.0/24
                                                    ip4:72.21.196.0/22 ip4:72.21.208.0/24 ip4:72.21.205.0/24
                                                    ip4:72.21.209.0/24 ip4:194.154.193.200/28 ip4:194.7.41.152/28
                                                    ip4:212.123.28.40/32 ip4:203.81.17.0/24 ~all"
    amazon.com.             3592    IN      TXT     "v=spf1 ip4:207.171.160.0/19 ip4:87.238.80.0/21 ip4:72.21.193.0/24
                                                    ip4:72.21.196.0/22 ip4:72.21.208.0/24 ip4:72.21.205.0/24
                                                    ip4:72.21.209.0/24 ip4:194.154.193.200/28 ip4:194.7.41.152/28
                                                    ip4:212.123.28.40/32 ip4:203.81.17.0/24 ~all"

    ;; Query time: 0 msec
    ;; SERVER: 127.0.0.1#53(127.0.0.1)
    ;; WHEN: Wed Sep 15 20:21:49 2010
    ;; MSG SIZE  rcvd: 516

With an unpatched 1.9.2 Resolv::DNS:

    >> pp Resolv::DNS.new.getresources('amazon.com', Resolv::DNS::Resource::IN::TXT); nil
    [#<Resolv::DNS::Resource::IN::TXT:0x0000000143b0b0
      @strings=
       ["spf2.0/pra ip4:207.171.160.0/19 ip4:87.238.80.0/21 ip4:72.21.193.0/24 ip4:72.21.196.0/22
        ip4:72.21.208.0/24 ip4:72.21.205.0/24 ip4:72.21.209.0/24 ip4:194.154.193.200/28 ip4:194.7.41.152/28
        ip4:212.123.28.40/32 ip4:203.81.17.0/24 ~all"],
      @ttl=2185>]
    => nil

The attached patch changes Resolv::DNS#each_resource to check UDP responses for truncation and retries via TCP, which is the proper behavior per RFC 1123, section 6.1.3.2 <http://tools.ietf.org/html/rfc1123#page-75> and implemented by most resolver libraries.

Effect:

    >> pp Resolv::DNS.new.getresources('amazon.com', Resolv::DNS::Resource::IN::TXT); nil
    [#<Resolv::DNS::Resource::IN::TXT:0x0000000214adf0
      @strings=
       ["spf2.0/pra ip4:207.171.160.0/19 ip4:87.238.80.0/21 ip4:72.21.193.0/24 ip4:72.21.196.0/22
        ip4:72.21.208.0/24 ip4:72.21.205.0/24 ip4:72.21.209.0/24 ip4:194.154.193.200/28 ip4:194.7.41.152/28
        ip4:212.123.28.40/32 ip4:203.81.17.0/24 ~all"],
      @ttl=2237>,
     #<Resolv::DNS::Resource::IN::TXT:0x0000000214a580
      @strings=
       ["v=spf1 ip4:207.171.160.0/19 ip4:87.238.80.0/21 ip4:72.21.193.0/24 ip4:72.21.196.0/22
        ip4:72.21.208.0/24 ip4:72.21.205.0/24 ip4:72.21.209.0/24 ip4:194.154.193.200/28 ip4:194.7.41.152/28
        ip4:212.123.28.40/32 ip4:203.81.17.0/24 ~all"],
      @ttl=2237>]
    => nil

I'm also attaching a patch for 1.8.7 in the hope that it will be merged into 1.8.7, too.

Of course it would be nice to also support EDNS0, but that's beyond what I can deliver right now.


----------------------------------------
http://redmine.ruby-lang.org

Attachments (2)

resolv-1.9.2-tcp-fallback.diff (1.84 KB, text/x-diff)
--- /usr/lib/ruby/1.9.2/resolv.rb	2010-09-12 14:47:47.000000000 +0000
+++ resolv-1.9.2.rb	2010-09-15 20:42:19.035523123 +0000
@@ -492,7 +492,7 @@
 
     def each_resource(name, typeclass, &proc)
       lazy_initialize
-      requester = make_requester
+      requester = make_udp_requester
       senders = {}
       begin
         @config.resolv(name) {|candidate, tout, nameserver, port|
@@ -506,7 +506,18 @@
           reply, reply_name = requester.request(sender, tout)
           case reply.rcode
           when RCode::NoError
-            extract_resources(reply, reply_name, typeclass, &proc)
+            if reply.tc and not Requester::TCP === requester
+              # Retry via TCP:
+              requester = make_tcp_requester
+              senders = {}
+              # This will use TCP for all remaining candidates (assuming the
+              # current candidate does not already respond successfully via
+              # TCP).  This makes sense because we already know the full
+              # response will not fit in an untruncated UDP packet.
+              redo
+            else
+              extract_resources(reply, reply_name, typeclass, &proc)
+            end
             return
           when RCode::NXDomain
             raise Config::NXDomain.new(reply_name.to_s)
@@ -519,7 +530,7 @@
       end
     end
 
-    def make_requester # :nodoc:
+    def make_udp_requester # :nodoc:
       nameserver_port = @config.nameserver_port
       if nameserver_port.length == 1
         Requester::ConnectedUDP.new(*nameserver_port[0])
@@ -528,6 +539,11 @@
       end
     end
 
+    def make_tcp_requester # :nodoc:
+      nameserver_port = @config.nameserver_port
+      return Requester::TCP.new(*nameserver_port[0])
+    end
+
     def extract_resources(msg, name, typeclass) # :nodoc:
       if typeclass < Resource::ANY
         n0 = Name.create(name)
resolv-1.8.7-tcp-fallback.diff (1.83 KB, text/x-diff)
--- /usr/lib/ruby/1.8/resolv.rb	2010-05-22 13:31:52.000000000 +0000
+++ resolv-1.8.7.rb	2010-09-15 20:39:41.555445345 +0000
@@ -475,7 +475,7 @@
   
     def each_resource(name, typeclass, &proc)
       lazy_initialize
-      requester = make_requester
+      requester = make_udp_requester
       senders = {}
       begin
         @config.resolv(name) {|candidate, tout, nameserver|
@@ -489,7 +489,18 @@
           reply, reply_name = requester.request(sender, tout)
           case reply.rcode
           when RCode::NoError
-            extract_resources(reply, reply_name, typeclass, &proc)
+            if reply.tc and not Requester::TCP === requester
+              # Retry via TCP:
+              requester = make_tcp_requester
+              senders = {}
+              # This will use TCP for all remaining candidates (assuming the
+              # current candidate does not already respond successfully via
+              # TCP).  This makes sense because we already know the full
+              # response will not fit in an untruncated UDP packet.
+              redo
+            else
+              extract_resources(reply, reply_name, typeclass, &proc)
+            end
             return
           when RCode::NXDomain
             raise Config::NXDomain.new(reply_name.to_s)
@@ -502,7 +513,7 @@
       end
     end
 
-    def make_requester # :nodoc:
+    def make_udp_requester # :nodoc:
       nameserver_port = @config.nameserver_port
       if nameserver_port.length == 1
         Requester::ConnectedUDP.new(*nameserver_port[0])
@@ -511,6 +522,11 @@
       end
     end
 
+    def make_tcp_requester # :nodoc:
+      nameserver_port = @config.nameserver_port
+      return Requester::TCP.new(*nameserver_port[0])
+    end
+
     def extract_resources(msg, name, typeclass) # :nodoc:
       if typeclass < Resource::ANY
         n0 = Name.create(name)

In This Thread

Prev Next