Board index » delphi » INDY and cookies to the HTTP Server's client

INDY and cookies to the HTTP Server's client

Hi all,

My application is a web server that uses the TIdHTTPServer component. I'm
keeping track of user sessions, so the server tries to write cookies to the
web client. This works great for both Netscape and IE browsers on the
Windows platform and for Netscape on the Macintosh platform. However, for IE
on Macintosh (version 5.0), my web server does not seem to be able to write
cookies to the browser (it doesn't even seem to make an attempt, as the
client's browser settings are to alert for cookies before accepting and no
alert box pops up). Is there anyone else having this problem? Anyone have
suggestions for a solution?

I thought it might be my code, so I tried this running with Indy's sample
web server, with user sessions managed. I still get this problem. Is this a
bug in Indy (I've got version 8.009b installed for Delphi 5/Win98)? If so,
please let me know. I'm running out of ideas :-(

Thanks a bunch!

Sivia

 

Re:INDY and cookies to the HTTP Server's client


Hi Stephane,

I've looked into the problem a little more closely. The problem seems to be
with the way cookies are being written to the Macintosh IE client. To
demonstrate, I've added session ID to the event log of the demo.

I've added an additional page to the demo, that will link to a second page
(test.html)
As you will see, the Win client retains the same session ID throughout,
however the Mac IE client's session ID changes each time, presumably due to
problems with the Mac IE client writing cookies. I've also included the Mac
Netscape client to show that the problem is indeed with the Mac IE client.

Please let me know if you have any ideas on how to fix or work around this
problem.

Thanks a bunch!

Sivia

The log as from a Win98 IE5.5 client:
Command GET / received from 172.16.5.32:3206Session ID=nJORpTxZJUV3Lwd
Command GET / received from 172.16.5.32:3207Session ID=nJORpTxZJUV3Lwd
Serving file C:\DCMPNTS\INDY\DEMOS\HTTPSERVER\Web\\index.html (8038 bytes /
8038 bytes sent) to 172.16.5.32:3207
Command GET /Jedi.gif received from 172.16.5.32:3209Session
ID=nJORpTxZJUV3Lwd
Serving file C:\DCMPNTS\INDY\DEMOS\HTTPSERVER\Web\Jedi.gif (3350 bytes /
3350 bytes sent) to 172.16.5.32:3209
Command GET /OSLogo.gif received from 172.16.5.32:3208Session
ID=nJORpTxZJUV3Lwd
Serving file C:\DCMPNTS\INDY\DEMOS\HTTPSERVER\Web\OSLogo.gif (1808 bytes /
1808 bytes sent) to 172.16.5.32:3208
Command GET /test.html received from 172.16.5.32:3210Session
ID=nJORpTxZJUV3Lwd
Serving file C:\DCMPNTS\INDY\DEMOS\HTTPSERVER\Web\test.html (8126 bytes /
8126 bytes sent) to 172.16.5.32:3210
Command GET /winshoes_logo.gif received from 172.16.5.32:3211Session
ID=nJORpTxZJUV3Lwd
Serving file C:\DCMPNTS\INDY\DEMOS\HTTPSERVER\Web\winshoes_logo.gif (11689
bytes / 11689 bytes sent) to 172.16.5.32:3211
Command GET /OSLogo.gif received from 172.16.5.32:3212Session
ID=nJORpTxZJUV3Lwd
Serving file C:\DCMPNTS\INDY\DEMOS\HTTPSERVER\Web\OSLogo.gif (1808 bytes /
1808 bytes sent) to 172.16.5.32:3212
Command GET /Jedi.gif received from 172.16.5.32:3213Session
ID=nJORpTxZJUV3Lwd
Serving file C:\DCMPNTS\INDY\DEMOS\HTTPSERVER\Web\Jedi.gif (3350 bytes /
3350 bytes sent) to 172.16.5.32:3213

The log as from a Mac IE4.5 client:
Command GET / received from 172.16.5.65:49199Session ID=IxAZPi3fsaZ1QqG
Starting session  at 10:48:06 AM
Command GET / received from 172.16.5.65:49200Session ID=LKyawlqOxRg96w9
Serving file C:\DCMPNTS\INDY\DEMOS\HTTPSERVER\Web\\index.html (8038 bytes /
8038 bytes sent) to 172.16.5.65:49200
Starting session  at 10:48:08 AM
Command GET /Jedi.gif received from 172.16.5.65:49201Session
ID=Q6D8WVZXBMPmSxp
Serving file C:\DCMPNTS\INDY\DEMOS\HTTPSERVER\Web\Jedi.gif (3350 bytes /
3350 bytes sent) to 172.16.5.65:49201
Starting session  at 10:48:10 AM
Command GET /test.html received from 172.16.5.65:49202Session
ID=AapYI8FCKm8JjLv
Serving file C:\DCMPNTS\INDY\DEMOS\HTTPSERVER\Web\test.html (8126 bytes /
8126 bytes sent) to 172.16.5.65:49202
Starting session  at 10:48:12 AM
Command GET /winshoes_logo.gif received from 172.16.5.65:49203Session
ID=aQlTzYM6MprI5pp
Ending session aQlTzYM6MprI5pp at 10:48:36 AM
Session duration was: -0.000281828703009523
Ending session AapYI8FCKm8JjLv at 10:48:36 AM
Session duration was: -0.000304976849292871
Ending session Q6D8WVZXBMPmSxp at 10:48:36 AM
Session duration was: -0.000328125002852175
Ending session LKyawlqOxRg96w9 at 10:48:36 AM
Session duration was: -0.000351273149135523
Ending session IxAZPi3fsaZ1QqG at 10:48:36 AM

The log as from a Mac Netscape 4.6 client:
Command GET / received from 172.16.5.65:1306Session ID=GqV79Hy7tnkj4GH
Command GET / received from 172.16.5.65:1307Session ID=GqV79Hy7tnkj4GH
Serving file C:\DCMPNTS\INDY\DEMOS\HTTPSERVER\Web\\index.html (8038 bytes /
8038 bytes sent) to 172.16.5.65:1307
Command GET /Jedi.gif received from 172.16.5.65:1309Session
ID=GqV79Hy7tnkj4GH
Serving file C:\DCMPNTS\INDY\DEMOS\HTTPSERVER\Web\Jedi.gif (3350 bytes /
3350 bytes sent) to 172.16.5.65:1309
Command GET /OSLogo.gif received from 172.16.5.65:1308Session
ID=GqV79Hy7tnkj4GH
Serving file C:\DCMPNTS\INDY\DEMOS\HTTPSERVER\Web\OSLogo.gif (1808 bytes /
1808 bytes sent) to 172.16.5.65:1308
Command GET /test.html received from 172.16.5.65:1310Session
ID=GqV79Hy7tnkj4GH
Serving file C:\DCMPNTS\INDY\DEMOS\HTTPSERVER\Web\test.html (8126 bytes /
8126 bytes sent) to 172.16.5.65:1310
Command GET /winshoes_logo.gif received from 172.16.5.65:1311Session
ID=GqV79Hy7tnkj4GH
Serving file C:\DCMPNTS\INDY\DEMOS\HTTPSERVER\Web\winshoes_logo.gif (11689
bytes / 11689 bytes sent) to 172.16.5.65:1311

Quote
"Stephane Grobety" <grob...@fulgan.com> wrote in message

news:900450FB5grobetyfulgancom@207.105.83.65...
Quote
> The HTTP Server code doesn't even check the browser type. It sends the
> cookie information regardless of what you throw at him.

> However, the HTTPServer comp uses "session" cookies (cookies that are not
> to be stored in the user's cookie jar) and therefore the setting "Warn
> before accepting cookies" might not apply at all. Check the setting of the
> "Per session cookie" behavior.

> Good luck,
> Stephane

> On 08 Dec 2000, si...@telus.net (Sivia) wrote in <3a3031b3_1@dnews>:

> >Hi all,

> >My application is a web server that uses the TIdHTTPServer component.
> >I'm keeping track of user sessions, so the server tries to write cookies
> >to the web client. This works great for both Netscape and IE browsers on
> >the Windows platform and for Netscape on the Macintosh platform.
> >However, for IE on Macintosh (version 5.0), my web server does not seem
> >to be able to write cookies to the browser (it doesn't even seem to make
> >an attempt, as the client's browser settings are to alert for cookies
> >before accepting and no alert box pops up). Is there anyone else having
> >this problem? Anyone have suggestions for a solution?

> >I thought it might be my code, so I tried this running with Indy's
> >sample web server, with user sessions managed. I still get this problem.
> >Is this a bug in Indy (I've got version 8.009b installed for Delphi
> >5/Win98)? If so, please let me know. I'm running out of ideas :-(

> >Thanks a bunch!

> >Sivia

Re:INDY and cookies to the HTTP Server's client


It looks like a problem with the way the Mac client stores the cookies.

Have you checked the release notes regarding this fact ?? This is clearely a
client problem so I'm not sure how we could fix this. Do you have any problem
with, say, ASP-Based session cookies ??

Good luck,
stephane

On 08 Dec 2000, si...@telus.net (Sivia) wrote in <3a313167$1_1@dnews>:

Quote
>Hi Stephane,

>I've looked into the problem a little more closely. The problem seems to
>be with the way cookies are being written to the Macintosh IE client. To
>demonstrate, I've added session ID to the event log of the demo.

>I've added an additional page to the demo, that will link to a second
>page (test.html)

>As you will see, the Win client retains the same session ID throughout,
>however the Mac IE client's session ID changes each time, presumably due
>to problems with the Mac IE client writing cookies. I've also included
>the Mac Netscape client to show that the problem is indeed with the Mac
>IE client.

>Please let me know if you have any ideas on how to fix or work around
>this problem.

>Thanks a bunch!

>Sivia

Re:INDY and cookies to the HTTP Server's client


Hi Stephane,

Quote
> Have you checked the release notes regarding this fact ?? This is clearely
a
> client problem so I'm not sure how we could fix this. Do you have any
problem
> with, say, ASP-Based session cookies ??

Do you mean using PWS or IIE? If so, seems to work fine.

I've asked around about the cookie problem (making sure that the cookies
complied with the RFC which defines cookies) and I've found this: (hopefully
it will help)

This is what Indy sends, which doesn't work:
Set-Cookie: IDHTTPSESSIONID: Xy1fIMVxDPgI1od

This is from a MivaScript server. It works on Mac IE:
Set-Cookie: htscallerid=3A255102000B106A00013EA300000000; expires=Wed,
19-Dec-2001 19:05:24 GMT; path=/

Here's the definition of the SetCookie header from RFC2109:
<http://www.faqs.org/rfcs/rfc2109.html>

4.2.2  Set-Cookie Syntax

  The syntax for the Set-Cookie response header is

  set-cookie      =       "Set-Cookie:" cookies
  cookies         =       1#cookie
  cookie          =       NAME "=" VALUE *(";" cookie-av)
  NAME            =       attr
  VALUE           =       value
  cookie-av       =       "Comment" "=" value
                  |       "Domain" "=" value
                  |       "Max-Age" "=" value
                  |       "Path" "=" value
                  |       "Secure"
                  |       "Version" "=" 1*DIGIT

  Informally, the Set-Cookie response header comprises the token Set-
  Cookie:, followed by a comma-separated list of one or more cookies.
  Each cookie begins with a NAME=VALUE pair, followed by zero or more
  semi-colon-separated attribute-value pairs.  The syntax for
  attribute-value pairs was shown earlier.  The specific attributes and
  the semantics of their values follows.  The NAME=VALUE attribute-
  value pair must come first in each cookie.  The others, if present,
  can occur in any order.  If an attribute appears more than once in a
  cookie, the behavior is undefined.

  NAME=VALUE
     Required.  The name of the state information ("cookie") is NAME,
     and its value is VALUE.  NAMEs that begin with $ are reserved for
     other uses and must not be used by applications.

     The VALUE is opaque to the user agent and may be anything the
     origin server chooses to send, possibly in a server-selected
     printable ASCII encoding.  "Opaque" implies that the content is of
     interest and relevance only to the origin server.  The content
     may, in fact, be readable by anyone that examines the Set-Cookie
     header.

  Comment=comment
     Optional.  Because cookies can contain private information about a
     user, the Cookie attribute allows an origin server to document its
     intended use of a cookie.  The user can inspect the information to
     decide whether to initiate or continue a session with this cookie.

  Domain=domain
     Optional.  The Domain attribute specifies the domain for which the
     cookie is valid.  An explicitly specified domain must always start
     with a dot.

  Max-Age=delta-seconds
     Optional.  The Max-Age attribute defines the lifetime of the
     cookie, in seconds.  The delta-seconds value is a decimal non-
     negative integer.  After delta-seconds seconds elapse, the client
     should discard the cookie.  A value of zero means the cookie
     should be discarded immediately.

  Path=path
     Optional.  The Path attribute specifies the subset of URLs to
     which this cookie applies.

  Secure
     Optional.  The Secure attribute (with no value) directs the user
     agent to use only (unspecified) secure means to contact the origin
     server whenever it sends back this cookie.

     The user agent (possibly under the user's control) may determine
     what level of security it considers appropriate for "secure"
     cookies.  The Secure attribute should be considered security
     advice from the server to the user agent, indicating that it is in
     the session's interest to protect the cookie contents.

  Version=version
     Required.  The Version attribute, a decimal integer, identifies to
     which version of the state management specification the cookie
     conforms.  For this specification, Version=1 applies.

Re:INDY and cookies to the HTTP Server's client


Hi Stephane,

Quote
> Have you checked the release notes regarding this fact ?? This is clearely
a
> client problem so I'm not sure how we could fix this. Do you have any
problem
> with, say, ASP-Based session cookies ??

Do you mean using PWS or IIE? If so, seems to work fine.
I've asked around about the cookie problem (making sure that the cookies
complied with the RFC which defines cookies) and I've found this: (hopefully
it will help)

This is what Indy sends, which doesn't work:
Set-Cookie: IDHTTPSESSIONID: Xy1fIMVxDPgI1od

This is from a MivaScript server. It works on Mac IE:
Set-Cookie: htscallerid=3A255102000B106A00013EA300000000; expires=Wed,
19-Dec-2001 19:05:24 GMT; path=/

Here's the definition of the SetCookie header from RFC2109:
<http://www.faqs.org/rfcs/rfc2109.html>

4.2.2  Set-Cookie Syntax

  The syntax for the Set-Cookie response header is

  set-cookie      =       "Set-Cookie:" cookies
  cookies         =       1#cookie
  cookie          =       NAME "=" VALUE *(";" cookie-av)
  NAME            =       attr
  VALUE           =       value
  cookie-av       =       "Comment" "=" value
                  |       "Domain" "=" value
                  |       "Max-Age" "=" value
                  |       "Path" "=" value
                  |       "Secure"
                  |       "Version" "=" 1*DIGIT

  Informally, the Set-Cookie response header comprises the token Set-
  Cookie:, followed by a comma-separated list of one or more cookies.
  Each cookie begins with a NAME=VALUE pair, followed by zero or more
  semi-colon-separated attribute-value pairs.  The syntax for
  attribute-value pairs was shown earlier.  The specific attributes and
  the semantics of their values follows.  The NAME=VALUE attribute-
  value pair must come first in each cookie.  The others, if present,
  can occur in any order.  If an attribute appears more than once in a
  cookie, the behavior is undefined.

  NAME=VALUE
     Required.  The name of the state information ("cookie") is NAME,
     and its value is VALUE.  NAMEs that begin with $ are reserved for
     other uses and must not be used by applications.

     The VALUE is opaque to the user agent and may be anything the
     origin server chooses to send, possibly in a server-selected
     printable ASCII encoding.  "Opaque" implies that the content is of
     interest and relevance only to the origin server.  The content
     may, in fact, be readable by anyone that examines the Set-Cookie
     header.

  Comment=comment
     Optional.  Because cookies can contain private information about a
     user, the Cookie attribute allows an origin server to document its
     intended use of a cookie.  The user can inspect the information to
     decide whether to initiate or continue a session with this cookie.

  Domain=domain
     Optional.  The Domain attribute specifies the domain for which the
     cookie is valid.  An explicitly specified domain must always start
     with a dot.

  Max-Age=delta-seconds
     Optional.  The Max-Age attribute defines the lifetime of the
     cookie, in seconds.  The delta-seconds value is a decimal non-
     negative integer.  After delta-seconds seconds elapse, the client
     should discard the cookie.  A value of zero means the cookie
     should be discarded immediately.

  Path=path
     Optional.  The Path attribute specifies the subset of URLs to
     which this cookie applies.

  Secure
     Optional.  The Secure attribute (with no value) directs the user
     agent to use only (unspecified) secure means to contact the origin
     server whenever it sends back this cookie.

     The user agent (possibly under the user's control) may determine
     what level of security it considers appropriate for "secure"
     cookies.  The Secure attribute should be considered security
     advice from the server to the user agent, indicating that it is in
     the session's interest to protect the cookie contents.

  Version=version
     Required.  The Version attribute, a decimal integer, identifies to
     which version of the state management specification the cookie
     conforms.  For this specification, Version=1 applies.

Re:INDY and cookies to the HTTP Server's client


Following replacement fixes this problem:

function TIdHTTPServer.CreateSession(HTTPResponse: TIdHTTPResponseInfo;
HTTPRequest: TIdHTTPRequestInfo): TIdHTTPSession;
var
  SessionID: string;
begin
  if SessionState then begin
    SessionID := getRandomString(15);
    result := FSessionList.CreateSession(HTTPrequest.RemoteIP, SessionID);
    HTTPResponse.Cookies.Append('IDHTTPSESSIONID=' + SessionID + ';
Path=/');
    HTTPResponse.FSession := result;
    HTTPRequest.FSession := result;
  end else begin
    result := nil;
  end;
end;

Quote
"Stephane Grobety" <grob...@fulgan.com> wrote in message

news:90078906Dgrobetyfulgancom@207.105.83.65...
Quote
> It looks like a problem with the way the Mac client stores the cookies.

> Have you checked the release notes regarding this fact ?? This is clearely
a
> client problem so I'm not sure how we could fix this. Do you have any
problem
> with, say, ASP-Based session cookies ??

> Good luck,
> stephane

> On 08 Dec 2000, si...@telus.net (Sivia) wrote in <3a313167$1_1@dnews>:

> >Hi Stephane,

> >I've looked into the problem a little more closely. The problem seems to
> >be with the way cookies are being written to the Macintosh IE client. To
> >demonstrate, I've added session ID to the event log of the demo.

> >I've added an additional page to the demo, that will link to a second
> >page (test.html)

> >As you will see, the Win client retains the same session ID throughout,
> >however the Mac IE client's session ID changes each time, presumably due
> >to problems with the Mac IE client writing cookies. I've also included
> >the Mac Netscape client to show that the problem is indeed with the Mac
> >IE client.

> >Please let me know if you have any ideas on how to fix or work around
> >this problem.

> >Thanks a bunch!

> >Sivia

Re:INDY and cookies to the HTTP Server's client


Quote
"Tania Jones" <tania.jo...@discoverysoftware.com> wrote in message

news:3a5380d1_1@dnews...

Quote
> Following replacement fixes this problem:
[snip]
>     HTTPResponse.Cookies.Append('IDHTTPSESSIONID=' + SessionID + ';
> Path=/');

(Posted to the NG with CC to Tania)

Thank you, Tania. I'll make sure it gets added when I revise our cookie
support (I hope to make some headway this weekend). If I for any reason
forget this (or get it wrong), don't hesitate to file a small bugreport once
8.00.14B is out!

--
Rune

Other Threads