Gerhard, I'm new to this particular task, so please forgive as I take a few missteps on how to report problems. Through my own challenges I'm also locked out of my d.o user account right now*. I've worked over the issue queue and only this issue appears to be related to the bug I found in 4.7.5: http://drupal.org/node/104693 I just brought down the 4.7.5 through cvs up onto my site, www.folkjam.org. I make heavy use of Google geocoding on the site and it broke. From what I can tell I am getting a timeout when attempting to use drupal_http_request to maps.google.com. I reverted just common.inc to the version I was running and our Google geocode requests began to work again. Within common.inc:drupal_http_request() this is the change that causes the problem: $request = $method .' '. $path ." HTTP/1.1\r\n"; is new $request = $method .' '. $path ." HTTP/1.0\r\n"; is what it was. Using HTTP1.1 my request fails (it looks to time out) and returns an empty result. Using HTTP 1.0 my request works. Sorry for using this forum to report the problem. I'll get myself back into d.o as soon as I learn how to configure mod_security correctly. I'm picking security over being able to get into d.o right now. Scott * A recent hosting provider move to dedicated hosting has a new mod_security setup that blocks d.o authentication against my personal site for federated login with error 406. I'm new to mod_security configuration. I've worked out how to tell mod_security to perform no security checks on /xmlrpc.php, but I have not yet worked out how to tell it to perform no checks for 140.211.166.46 (d.o) but check for everybody else. I'm not willing to leave it open, so I'm locked out of d.o until I fix this. Which I'll get to. If there is anybody out there expert enough on mod_security to help, please contact me off-list. Gerhard Killesreiter wrote:

Gerhard Killesreiter wrote:

...

Hi there,

I want to release a 4.7.5 before Chistmas, but I am running a bit low on time, so it might be next week. I've committed all the issues with "ready to go" patches, but I think there are a few bugs which would be nice to fix and need a review and testing:

http://drupal.org/node/102962 http://drupal.org/node/87372 http://drupal.org/node/82397

and of course the rest of

http://drupal.org/project/issues?projects=3060&versions=97573,94735,94733,94...

snf of courdse I forgot to mention that it would be helpful if people could get the 4.7-CVS tarball or a CVS checkout and test it so we knwo we don't ship a broken release.

http://drupal.org/drupal-4.7.x-dev

Cheers, Gerhard

Gerhard,

...

http://drupal.org/node/104693

Thanks, I've reverted that patch. Ok good. I'll bring down 4.7.5 to our test site again and continue to work it over. One of our users reported what sounds like the duplicate cookie sessions problem just last night. I was pleased to see that issue as one of the three you drew attention to

Drupal.org has two IPs, 140.211.166.46 and 140.211.166.61. Good to know. I've got both in there now. I was only ever seeing the .46 one attempt to authenticate me.

I think mod_security is a module that creates a lot of difficult to track down problems... Depending on configuration is breaks forms that contain values that it disapproves of. Completely harmless values. That is a much nicer description than I would have given it. I leave it in because it's one of those things that I don't fully understand, our provider's admin strongly recommends it be on, and I cannot quantify the impact of not having it.

Scott