Closed (duplicate)
Project:
Drupal core
Version:
6.x-dev
Component:
system.module
Priority:
Critical
Category:
Bug report
Assigned:
Reporter:
Created:
25 Mar 2007 at 23:41 UTC
Updated:
30 Apr 2007 at 11:16 UTC
Jump to comment: Most recent file
Comments
Comment #1
harry slaughterWe will certainly want to optimize the regexes in this settings.php code.
for example, clouseau suggested using something like
/.\d{1,3}$/instead of
/\d{1,3}.\d{1,4}.\d{1,3}.\d{1,3}/It's obviously important that settings.php not contain any unnecessary overhead.
Comment #2
harry slaughterquick follow up, benchmarked the patch and there's no need to optimize anything.
Comment #3
drummLooks okay, but why only benchmark the existing function and not the new one?
Comment #4
dries commentedWhat exactly does this patch fix? What's wrong with using an IP address and/or port number?
Comment #5
Steven commentedYou cannot set cookie domains to IPs as per the RFC. Same for port numbers. It must be a domain only.
Comment #6
johnalbinI noticed one additional problem with the existing cookie_domain code… it doesn’t strip the text “www.” from the front of the HTTP_HOST, it strips the regular expression “www.” from the front of the HTTP_HOST. (Right now, some guy at http://wwwisforsuckas.example.com is weeping because he can't login to his Drupal.)
The attached patch fixes all the 3 issues while incurring very little performance hit, since it simply expands the regex in the existing
preg_replace()call.Comment #7
johnalbinModifying title to better explain issue.
Comment #8
johnalbinRe-rolled patch against latest 6.x.
Comment #9
Zen commentedIsn't this being addressed in http://drupal.org/node/56357 as well?
-K
Comment #10
johnalbinYes. The patch in #56357 grew in scope to incapsulate a fix for this issue. But since they are separate issues and neither committed, I’m not comfortable with me setting this issue to duplicate until #56357 is in HEAD.
Comment #11
dries commentedLet's move this to: http://drupal.org/node/56357 ...