RE: mod_perl not sending cookies
Usually when I have this problem the path and/or domain is incorrect. Try it without either. Tom -Original Message- From: Andrew Fritz [mailto:[EMAIL PROTECTED] Sent: Thursday, March 13, 2003 12:25 PM To: [EMAIL PROTECTED] Subject: mod_perl not sending cookies I'm using Apache:AuthCookie. I have set up a basic test site. It appears that AuthCookie never send the cookie even though the call to: $r-err_headers_out-add(Set-Cookie = $cookie); is there. If I modify the call to include a simple cookie: $r-err_headers_out-add(Set-Cookie = 'a=b'); it works. The value of $cookie is: jza70AuthHandler_JZA70=\Thisisatest\; expires=Tue, 11 Mar 2003 06:33:50 GMT; path=/thisisatest; domain=jza70 The expires field is from a log of a few days ago, but was valid (about 24 hours in the future) when it was sent. Any thoughts are apreciated. Andrew Fritz
RE: mod_perl not sending cookies
Andrew, Ya need to remember to CC the group as well. Copied from an oldish Netscape spec: -- domain=DOMAIN_NAME When searching the cookie list for valid cookies, a comparison of the domain attributes of the cookie is made with the Internet domain name of the host from which the URL will be fetched. If there is a tail match, then the cookie will go through path matching to see if it should be sent. Tail matching means that domain attribute is matched against the tail of the fully qualified domain name of the host. A domain attribute of acme.com would match host names anvil.acme.com as well as shipping.crate.acme.com. Only hosts within the specified domain can set a cookie for a domain and domains must have at least two (2) or three (3) periods in them to prevent domains of the form: .com, .edu, and va.us. Any domain that fails within one of the seven special top level domains listed below only require two periods. Any other domain requires at least three. The seven special top level domains are: COM, EDU, NET, ORG, GOV, MIL, and INT. The default value of domain is the host name of the server which generated the cookie response. path=PATH The path attribute is used to specify the subset of URLs in a domain for which the cookie is valid. If a cookie has already passed domain matching, then the pathname component of the URL is compared with the path attribute, and if there is a match, the cookie is considered valid and is sent along with the URL request. The path /foo would match /foobar and /foo/bar.html. The path / is the most general path. If the path is not specified, it as assumed to be the same path as the document being described by the header which contains the cookie. -Original Message- From: Andrew Fritz [mailto:[EMAIL PROTECTED] Sent: Thursday, March 13, 2003 7:07 PM To: Tom Murphy Subject: Re: mod_perl not sending cookies Bingo! That did it. I removed the path and domain and it works. No, the dumb questions: any idea what they should be set to to make it work. I'm testing with my hosts file modified to point to a local virtual host (jza70) instead of going to a real DNS accessable domain name (jza70.com). Is that the issue or am I missunderstanding what the domain field is specifying. I thought it specified the owner of the cookie. I'm not sure about the path field. Andrew Tom Murphy wrote: Usually when I have this problem the path and/or domain is incorrect. Try it without either. Tom -Original Message- From: Andrew Fritz [mailto:[EMAIL PROTECTED] Sent: Thursday, March 13, 2003 12:25 PM To: [EMAIL PROTECTED] Subject: mod_perl not sending cookies I'm using Apache:AuthCookie. I have set up a basic test site. It appears that AuthCookie never send the cookie even though the call to: $r-err_headers_out-add(Set-Cookie = $cookie); is there. If I modify the call to include a simple cookie: $r-err_headers_out-add(Set-Cookie = 'a=b'); it works. The value of $cookie is: jza70AuthHandler_JZA70=\Thisisatest\; expires=Tue, 11 Mar 2003 06:33:50 GMT; path=/thisisatest; domain=jza70 The expires field is from a log of a few days ago, but was valid (about 24 hours in the future) when it was sent. Any thoughts are apreciated. Andrew Fritz
PerlCleanupHandler called from default-handler
I have written a Apache::DBILogger style log mechanism. It is enabled via the perl.conf in the Server context as: PerlCleanupHandler NC::LogHandler It works correctly, except for the fact that request handle by the default-handler do not call this handler. The mod_perl cookbook makes note that: ..a C module has to specifically want this processing to occur-it is not called automatically. How do I allow for this handler to be called on all requests? Note I also tried this as a PerlLogHandler to no avail. TIA, Tom Murphy
RE: crazy problem
Here's the gist ... when I run some code which looks like ... my result = `/usr/local/bin/matlab input_file.m`; ... from a perl CGI, then matlab (a commercial math package) segfaults. However, when I run it from mod_perl on the same server it runs fine (it runs fine from the command line, btw). Sounds like a dynamic lib problem. W/o knowing your OS its hard to say what variable Apache is setting but try looking at one of these SHLIB_PATH,LD_LIBRARY_PATH. For anyone who may have Matlab available, btw, this is only with Matlab 6. Matlab 5 (which we no longer have a license for) works just fine. Yup, I suspect Matlab 6 requires a newer shared library of some sort. Cheers, Tom Murphy
Access to ap_send_fd_length in 1.0
I have a client for whom I manage documents, some of which are in pdf format. The documents are not in the web tree, and are served based on custom access etc., and some are encrypted on the files system. I am successfully do all this, and ultimately use send_fd to send the file(s). The client has noticed that through the managed process, the time to view the pdf is longer than viewing the same file through the default handler. I have discovered that this is most likely due to the fact that Apache is byteserving the file, allowing the first page to be viewed even though the complete file has not been downloaded. The complete time to download between the default handler and my handler are quite close, but the document comes up for partial view much quicker with the default handler. I have been able to use Apache::File to modify my handler to recognize when a byteserving request has come in ( using ap_set_byterange), and access the ap_each_byterange call to decode the header. However, it does not seem like the ap_send_fd_length is mod_perl accessible. Is there any issue with adding access to this API function? Also, will I have a problem setting the PARTIAL_CONTENT response? With the clients encrypted documents, I have the documents in memory only. I would like to use the send_fb/send_fb_length call in a similar fashion. I haven't done any XS/guts type programming, so I'm hoping this will be a relatively simple task. Thanks for any pointers, Tom Murphy
