Closed Bug 223365 Opened 21 years ago Closed 21 years ago

Cookies are not sent when accessing localhost

Categories

(Core :: Networking: Cookies, defect)

Product:
Core
Component:
Networking: Cookies
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla1.6alpha

People

(Reporter: mozbug, Assigned: dwitte)

Details

(Keywords: regression)

Attachments

(3 files)

log when using http://localhost:8080/
441 bytes, text/plain
Details
log when using http://127.0.0.1:8080/
1.58 KB, text/plain
Details
make domainwalking to include toplevel domain
2.66 KB, patch
mvl
: review+
darin.moz
: superreview+
asa
: approval1.6a+
Details | Diff | Splinter Review 
When accessing the web applicatoin I develop by http://localhost:8080/, cookies
are not sent (checked with ethereal).

However by accessing http://127.0.0.1:8080/, cookies are sent.

Build 2003102222 shows this behaviour,
build 2003102022 does not.
(Both are linux trunk builds)
possibly regression from bug 143939 and bug 221185 (checked in on 10/21).
Keywords: regression
dwitte: is this yours?
the only thing i can think of here is the CheckDomain() test failing, but that
should occur regardless of my changes (assuming you have "domain=" attributes in
your Set-Cookie headers). if you don't have "domain=" attributes, it should work
fine.

reporter: please generate a cookie log (instructions for windows can be found at
http://bugzilla.mozilla.org/show_bug.cgi?id=193951#c1, same idea on linux), and
attach it here. hopefully that'll tell us what's failing...

    
    

    
  


  

    
    

    
  
ouch, this one's mine. regressions suck...
Assignee: darin → dwitte
OS: Linux → All
Hardware: PC → All
Target Milestone: --- → mozilla1.6alpha

    
    

    
  


  
so i deliberately made domainwalking not do this originally, since it saves a
hash lookup in almost all cases (no point in looking up .com in www.foo.com,
for instance). this adds that lookup back in... <sigh>

    
    

    
  
Comment on attachment 133961 [details] [diff] [review]
make domainwalking to include toplevel domain

can i get this for alpha, guys? thanks!

        Attachment #133961 -
        Flags: superreview?(darin)

        Attachment #133961 -
        Flags: review?(mvl)

        Attachment #133961 -
        Flags: review?(mvl) → review+

    
    

    
  
This is also happening to me when using server names on our intranet (no cookies
sent), but is ok when i change it to an ip address,
i.e. http://nlxcips06:81/utils/enterLogin.jsp fails to send cookies, but
http://130.144.1.2:81/utils/enterLogin.jsp works.

Mark

    
    

    
  
Comment on attachment 133961 [details] [diff] [review]
make domainwalking to include toplevel domain

>
><HTML><HEAD/><BODY><PRE>Index: netwerk/cookie/src/nsCookieService.cpp
>===================================================================
>RCS file: /cvsroot/mozilla/netwerk/cookie/src/nsCookieService.cpp,v
>retrieving revision 1.9
>diff -u -6 -p -d -r1.9 nsCookieService.cpp
>--- netwerk/cookie/src/nsCookieService.cpp	22 Oct 2003 06:53:19 -0000	1.9
>+++ netwerk/cookie/src/nsCookieService.cpp	23 Oct 2003 19:00:34 -0000
>@@ -577,14 +577,14 @@ nsCookieService::GetCookieStringFromHttp
>   nsAutoVoidArray foundCookieList;
>   nsInt64 currentTime = NOW_IN_SECONDS;
>   const char *currentDot = hostFromURI.get();
>   const char *nextDot = currentDot + 1;
> 
>   // begin hash lookup, walking up the subdomain levels.
>-  // we use nextDot to make sure we have at least one embedded dot remaining.
>-  while (nextDot) {
>+  // we use nextDot to force a lookup of the original host (without leading dot).
>+ do {
>     nsCookieEntry *entry = mHostTable.GetEntry(currentDot);
>     cookie = entry ? entry->Head() : nsnull;
>     for (; cookie; cookie = cookie->Next()) {
>       // if the cookie is secure and the host scheme isn't, we can't send it
>       if (cookie->IsSecure() && !isSecure) {
>         continue;
>@@ -624,14 +624,16 @@ nsCookieService::GetCookieStringFromHttp
>       // all checks passed - add to list and update lastAccessed stamp of cookie
>       foundCookieList.AppendElement(cookie);
>       cookie->SetLastAccessed(currentTime);
>     }
> 
>     currentDot = nextDot;
>-    nextDot = strchr(currentDot + 1, '.');
>-  }
>+    if (currentDot)
>+      nextDot = strchr(currentDot + 1, '.');
>+
>+  } while (currentDot);
> 
>   // return cookies in order of path length; longest to shortest.
>   // this is required per RFC2109.
>   foundCookieList.Sort(compareCookiesByPath, nsnull);
> 
>   nsCAutoString cookieData;
>@@ -2128,13 +2130,13 @@ nsCookieService::CountCookiesFromHost(ns
>   PRUint32 countFromHost = 0;
> 
>   nsCAutoString hostWithDot(NS_LITERAL_CSTRING(".") + aCookie->RawHost());
> 
>   const char *currentDot = hostWithDot.get();
>   const char *nextDot = currentDot + 1;
>-  while (nextDot) {
>+  do {
>     nsCookieEntry *entry = mHostTable.GetEntry(currentDot);
>     for (nsListIter iter(entry); iter.current; ++iter) {
>       // only count session or non-expired cookies
>       if (iter.current->IsSession() || iter.current->Expiry() > aData.currentTime) {
>         ++countFromHost;
> 
>@@ -2144,14 +2146,16 @@ nsCookieService::CountCookiesFromHost(ns
>           aData.iter = iter;
>         }
>       }
>     }
> 
>     currentDot = nextDot;
>-    nextDot = strchr(currentDot + 1, '.');
>-  }
>+    if (currentDot)
>+      nextDot = strchr(currentDot + 1, '.');
>+
>+  } while (currentDot);
> 
>   return countFromHost;
> }
> 
> // find an exact previous match.
> PRBool
></PRE></BODY></HTML>

        Attachment #133961 -
        Flags: superreview?(darin) → superreview+

    
    

    
  
Comment on attachment 133961 [details] [diff] [review]
make domainwalking to include toplevel domain

this is a simple regression fix for a landing i made just before the freeze...

        Attachment #133961 -
        Flags: approval1.6a?

    
    

    
  
Comment on attachment 133961 [details] [diff] [review]
make domainwalking to include toplevel domain

a=asa (on behalf of drivers) for checkin to 1.6alpha

        Attachment #133961 -
        Flags: approval1.6a? → approval1.6a+

    
    

    
  
fixed for alpha.
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: