We are at p204 but 1.9.3 is only at p194

The p204 stdlib comes from the 1.9.3 branch of MRI. Are there actually bugs in the intervening commits that are a problem?

FWIW, rolling back is a wee bit trickier than rolling forward, so if we can just punt on this until they do another release it would be preferable...

Okay. As of right now, it's kinda unusable for me. Net::HTTP is unable to properly handle any gzip'd responses in 1.9 mode. It seems p204 has a different Net::HTTP implementation for 1.9 than 1.8, whereas in p194 they're unified.

Ok...so here's the thing. If we have to downgrade, we can do that...it's not pleasant, but we can make it happen. What I'd prefer to see is that this gets fixed upstream in MRI and then we pull down the fixed official versions. Can you file an issue with MRI and link it here? We'll try to push (or help) to get this issue fixed upstream.

Sure. I was trying to verify it was still an issue upstream, but I've been unable to build HEAD at all. I'm not really sure what to file against since p204 doesn't actually exist from what I can tell. But I'll try to work that out this weekend.

p204 is what MRI reported as ruby -v when I did the latest stdlib update (from 1.9.3 branch). I'm not sure what they're on now.

Did you have any luck this weekend?

To clarify: you should build ruby_1_9_3 branch to confirm patchlevel and whether the issue is still there, and file against 1.9.3 as a regression/bug.

The following script illustrates the issue. With the bug in place, it will raise an Encoding::UndefinedConversionError.

require 'net/http'

Encoding.default_internal = Encoding::UTF_8

url = URI('http://www.wowzers.com/')
session = Net::HTTP::Proxy(nil, nil, nil, nil).new(url.host,url.port)
session.get('/')

NB: It seems to only fail when passed through the no-op proxy. When using Net::HTTP directly I couldn't induce the error.

Testing 1.9.3-head with your script.

Ruby master does not appear to fail your script. I will investigate if there has been a stdlib update that solves it and if that solves it for us.

Sounds good. There was also the open question as to whether this is really just an I/O encoding issue. I've tested with Tom's recent commits to master and the script still fails. But, I don't know if he has more to do still.

The work I landed recently was only for IO transcoding (zlib does not really use the same stuff), but I am looking at another zlib problem right now and I will also look at this case. They are potentially the same issue even.

FWIW, I raised the concern about being too far ahead of released 1.9.3 stdlib on ruby-core. So far no responses. At this point, I'm not planning to roll back, and probably will roll forward for pre2 since a new 1.9.3 release can't be far off (right?).

Commit da78396 fixes the transcoding raise. This issue is not technically about the raise but the discrepancy between pl with MRI.

I can confirm the script now works. But, yeah, the original issue still stands. While being on p203 no longer seems to be problematic, I think it's still confusing and can lead to weird debug scenarios if we don't ship with the same patch level as MRI.

Ok, I asked ruby-core about release cycles, and they're preparing to spin a new 1.9.3 release soon. I'm not sure how soon that is, but it will certainly be before JRuby 1.7 final.

I have also asked if it would be safe for us to roll to the most current stdlib from svn today, assuming the released version will be at least this patchlevel. So the problem is going to solve itself shortly, and after that we'll try to make sure we're matching patchlevel.

FWIW, the main reason I had been keeping up with svn rather than actual releases was to pick up bug fixes that were taking too long to reach the public. Obviously we could have been picking up bugs at the same time.

Still no help from ruby-core. It has been a couple months now and they have not released an updated 1.9.3.

It's apparent there won't be a 1.9.3 release soon enough to get updates into 1.7.0, so we'll go with what we have and try to match them for 1.7.1.

See JRUBY-6935.

Thanks Hiro. I guess for accuracy, would someone with permissions mind changing the title of this issue to to say "p203" instead of "p204?"