updating r->finfo on $r->filename($newfile)
hi all
just following up on a thread in new-httpd from the weekend :)
in mp1, whenever a user set the filename via $r->filename($newfile) mod_perl
would update r->finfo as well. the reason is because things like
default_handler do this
ap_update_mtime(r, r->finfo.mtime);
...
ap_set_content_length(r, r->finfo.size);
if ((errstatus = ap_meets_conditions(r)) != OK) {
...
so, if a handler sets r->filename after translation, the wrong value will be
used in the meets_conditions test, and the client will get bad data.
the attached patch carries this over to mp2.
the only outstanding issue for me is that in mp1, there was an exception for
Win32, which I didn't carry over, figuring apr now takes care of the compat
issues. I'm also hoping that utime (used in the test suite) is portable :)
so, I'd like to get some feedback/test results from Win32 before porting
this functionality to mp2.
--Geoff
Index: xs/Apache/RequestRec/Apache__RequestRec.h
===
RCS file: /home/cvspublic/modperl-2.0/xs/Apache/RequestRec/Apache__RequestRec.h,v
retrieving revision 1.6
diff -u -r1.6 Apache__RequestRec.h
--- xs/Apache/RequestRec/Apache__RequestRec.h 14 Mar 2003 05:34:24 - 1.6
+++ xs/Apache/RequestRec/Apache__RequestRec.h 27 Oct 2003 19:13:13 -
@@ -53,3 +53,33 @@
return modperl_table_get_set(aTHX_ r->subprocess_env,
key, val, TRUE);
}
+
+static MP_INLINE
+char *mpxs_Apache__RequestRec_filename(pTHX_ request_rec *r,
+ SV *name)
+{
+char *retval = r->filename;
+
+if (name) {
+STRLEN len;
+const char *val = SvPV(name, len);
+
+MP_TRACE_o(MP_FUNC, "setting r->filename to %s\n",
+ val);
+
+/* set r->filename to the incoming value */
+r->filename = apr_pstrndup(r->pool, val, len);
+
+/* and update r->finfo so later calcuations work properly */
+apr_status_t rv = apr_stat(&r->finfo, r->filename,
+ APR_FINFO_MIN, r->pool);
+
+if (rv != APR_SUCCESS) {
+ MP_TRACE_o(MP_FUNC, "unable to update finfo for %s\n",
+name);
+ r->finfo.filetype = 0;
+}
+}
+
+return retval;
+}
Index: xs/maps/apache_structures.map
===
RCS file: /home/cvspublic/modperl-2.0/xs/maps/apache_structures.map,v
retrieving revision 1.19
diff -u -r1.19 apache_structures.map
--- xs/maps/apache_structures.map 19 Feb 2003 14:12:02 - 1.19
+++ xs/maps/apache_structures.map 27 Oct 2003 19:13:13 -
@@ -51,7 +51,7 @@
no_local_copy
unparsed_uri
uri
- filename
+~ filename
canonical_filename
path_info
args
Index: xs/maps/modperl_functions.map
===
RCS file: /home/cvspublic/modperl-2.0/xs/maps/modperl_functions.map,v
retrieving revision 1.58
diff -u -r1.58 modperl_functions.map
--- xs/maps/modperl_functions.map 30 Aug 2003 02:33:26 - 1.58
+++ xs/maps/modperl_functions.map 27 Oct 2003 19:13:13 -
@@ -15,6 +15,7 @@
mpxs_Apache__RequestRec_content_type | | r, type=Nullsv
mpxs_Apache__RequestRec_proxyreq | | r, val=Nullsv
mpxs_Apache__RequestRec_subprocess_env | | r, key=NULL, val=Nullsv
+ mpxs_Apache__RequestRec_filename | | r, name=Nullsv
MODULE=Apache::RequestUtil PACKAGE=guess
mpxs_Apache__RequestRec_push_handlers
Index: xs/tables/current/ModPerl/FunctionTable.pm
===
RCS file: /home/cvspublic/modperl-2.0/xs/tables/current/ModPerl/FunctionTable.pm,v
retrieving revision 1.126
diff -u -r1.126 FunctionTable.pm
--- xs/tables/current/ModPerl/FunctionTable.pm 14 Oct 2003 17:32:40 - 1.126
+++ xs/tables/current/ModPerl/FunctionTable.pm 27 Oct 2003 19:13:17 -
@@ -5544,6 +5544,24 @@
]
},
{
+'return_type' => 'char *',
+'name' => 'mpxs_Apache__RequestRec_filename',
+'args' => [
+ {
+'type' => 'PerlInterpreter *',
+'name' => 'my_perl'
+ },
+ {
+'type' => 'request_rec *',
+'name' => 'r'
+ },
+ {
+'type' => 'SV *',
+'name' => 'name'
+ }
+]
+ },
+ {
'return_type' => 'SV *',
'name' => 'mpxs_Apache__RequestRec_get_handlers',
'args' => [
--- /dev/null 2003-01-30 05:24:37.0 -0500
+++ t/htdocs/modperl/change.html2003-10-27 14:04:21.0 -0500
@@ -0,0 +1,2 @@
+file used in t/modperl/filename.t
+$r->filename('htdocs/modperl/change.html');
--- /dev/null 2003-01-30 05:24:37.0 -0500
+++ t/modperl/filename.t2003-10-27 11:46:00.0 -0500
@@ -0,0 +1,92 @@
+use strict;
+use warnings FATAL => 'all';
+
+use Apache::Test;
+use Apache::TestRequest;
+use Apache::TestUtil
Re: updating r->finfo on $r->filename($newfile)
Geoffrey Young wrote:
hi all
just following up on a thread in new-httpd from the weekend :)
in mp1, whenever a user set the filename via $r->filename($newfile)
mod_perl would update r->finfo as well. the reason is because things
like default_handler do this
ap_update_mtime(r, r->finfo.mtime);
...
ap_set_content_length(r, r->finfo.size);
if ((errstatus = ap_meets_conditions(r)) != OK) {
...
so, if a handler sets r->filename after translation, the wrong value
will be used in the meets_conditions test, and the client will get bad
data.
+1, but won't be better for Apache provide an API to set r->filename which
will take care of updating finfo? If Apache doesn't provide this API, and
wants users to do that when they really want to (as it involves an overhead),
perhaps we shouldn't do that as we did in mp1 but instead document that one
has to update $r->finfo, if they need to and leave things 1:1 with C API.
Another idea would be to provide a variation of filename() which will set
filename and update finfo. e.g. filename_finfo()?
the attached patch carries this over to mp2.
the only outstanding issue for me is that in mp1, there was an exception
for Win32, which I didn't carry over, figuring apr now takes care of the
compat issues. I'm also hoping that utime (used in the test suite) is
portable :) so, I'd like to get some feedback/test results from Win32
before porting this functionality to mp2.
From perlport.pod:
utime LIST
Only the modification time is updated. (BeOS, Mac OS, VMS,
RISC OS)
May not behave as expected. Behavior depends on the C runtime
library's implementation of utime(), and the filesystem being
used. The FAT filesystem typically does not support an "access
time" field, and it may limit timestamps to a granularity of
two seconds. (Win32)
So it looks like you are safe, since all we want is the mod time.
And a few comments on the patch:
Index: xs/Apache/RequestRec/Apache__RequestRec.h
===
RCS file: /home/cvspublic/modperl-2.0/xs/Apache/RequestRec/Apache__RequestRec.h,v
retrieving revision 1.6
diff -u -r1.6 Apache__RequestRec.h
--- xs/Apache/RequestRec/Apache__RequestRec.h 14 Mar 2003 05:34:24 - 1.6
+++ xs/Apache/RequestRec/Apache__RequestRec.h 27 Oct 2003 19:13:13 -
@@ -53,3 +53,33 @@
return modperl_table_get_set(aTHX_ r->subprocess_env,
key, val, TRUE);
}
+
+static MP_INLINE
+char *mpxs_Apache__RequestRec_filename(pTHX_ request_rec *r,
+ SV *name)
+{
+char *retval = r->filename;
+
+if (name) {
+STRLEN len;
+const char *val = SvPV(name, len);
+
+MP_TRACE_o(MP_FUNC, "setting r->filename to %s\n",
+ val);
If you intend to keep these traces, they shouldn't be _o, which is used for
I/O tracing. _h (handlers) could be an OK choice, but may be introducing _a
(Apache interaction?) is a better idea?
--- /dev/null 2003-01-30 05:24:37.0 -0500
+++ t/modperl/filename.t2003-10-27 11:46:00.0 -0500
[...]
+ok utime(undef, undef, catfile(qw(htdocs index.html)));
+ok utime(undef, undef, catfile(qw(htdocs modperl change.html)));
please don't hardcode 'htdocs', see other tests that work with files, using
Apache::Test->config->vars->{documentroot}
[...]
+# touch index.html so that requests to it get 200
+# when using the old Last-Modified date
+
+sleep 2; # make sure we get a time difference
It's probably better to use the approach used in t/hooks/cleanup2.t, so you
sleep the minimal amount of time using a more finegrained select and checking
for the timestamp with -M will ensure that it'll certainly be different (in
case some OS has a bad sleep granularity).
__
Stas BekmanJAm_pH --> Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide ---> http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: updating r->finfo on $r->filename($newfile)
+1, but won't be better for Apache provide an API to set r->filename
which will take care of updating finfo?
yes, but you saw how quickly the thread died out when that idea was
introduced...
If Apache doesn't provide this
API, and wants users to do that when they really want to (as it involves
an overhead), perhaps we shouldn't do that as we did in mp1 but instead
document that one has to update $r->finfo, if they need to and leave
things 1:1 with C API.
except there's no $r->finfo API, right?
which brings me to my next question. IIRC, when we last talked about
$r->finfo you said it wasn't likely to happen since there is no apr_status_t
mapping for perl's stat() (or something like that :)
is it really impossible, or just a really complex typemap? I, for one, miss
$r->finfo activity, and would like to see _something_ in mp2. maybe an API
that's different from 1.0:
use Apache::Finfo ();
my $finfo = $r->finfo;
$finfo->update(stat $foo);
$mtime = (stat _)[9];
$finfo->size(-s $bar);
etc...
Another idea would be to provide a variation of filename() which will
set filename and update finfo. e.g. filename_finfo()?
maybe. I think either the apache API (which will never come) or our own
access to $r->finfo is a better approach.
So it looks like you are safe, since all we want is the mod time.
cool, thanks :)
If you intend to keep these traces, they shouldn't be _o, which is used
for I/O tracing.
I kinda thought is was IO, since the new logic involves (underlying) stat
calls. but ok - whatever you think is best is fine with me.
please don't hardcode 'htdocs', see other tests that work with files,
using Apache::Test->config->vars->{documentroot}
It's probably better to use the approach used in t/hooks/cleanup2.t, so
you sleep the minimal amount of time using a more finegrained select and
checking for the timestamp with -M will ensure that it'll certainly be
different (in case some OS has a bad sleep granularity).
ok, I'll change those.
--Geoff
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: updating r->finfo on $r->filename($newfile)
Geoffrey Young wrote: +1, but won't be better for Apache provide an API to set r->filename which will take care of updating finfo? yes, but you saw how quickly the thread died out when that idea was introduced... like most other threads on httdp-dev list, which were lucky at all to become a thread... If Apache doesn't provide this API, and wants users to do that when they really want to (as it involves an overhead), perhaps we shouldn't do that as we did in mp1 but instead document that one has to update $r->finfo, if they need to and leave things 1:1 with C API. except there's no $r->finfo API, right? which brings me to my next question. IIRC, when we last talked about $r->finfo you said it wasn't likely to happen since there is no apr_status_t mapping for perl's stat() (or something like that :) apr_finfo_t is it really impossible, or just a really complex typemap? Philippe has worked on it and he said that it won't work. See: http://marc.theaimsgroup.com/?l=apache-modperl-dev&m=104495193904477&w=2 I don't know if anything has changed since then. I, for one, miss $r->finfo activity, and would like to see _something_ in mp2. maybe an API that's different from 1.0: use Apache::Finfo (); my $finfo = $r->finfo; $finfo->update(stat $foo); $mtime = (stat _)[9]; $finfo->size(-s $bar); etc... Sure, that will work. Though you can't manipulate finfo struct directly with perl function, which is what mp1 did. Moreover we must be careful what accessors are provided. e.g. struct apr_file_t *filehand; returns a filehandle, which is not FILE. Though it could be made suitable for manipulation with APR::PerlIO. Another idea would be to provide a variation of filename() which will set filename and update finfo. e.g. filename_finfo()? maybe. I think either the apache API (which will never come) or our own access to $r->finfo is a better approach. right. If you intend to keep these traces, they shouldn't be _o, which is used for I/O tracing. I kinda thought is was IO, since the new logic involves (underlying) stat calls. but ok - whatever you think is best is fine with me. stat() != IO in a sense that you would want to use IO tracing if some data that you print is getting lost or corrupted. You would want to use some other tracing if you get the filestamp wrong, no? __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: updating r->finfo on $r->filename($newfile)
Stas Bekman wrote: Geoffrey Young wrote: +1, but won't be better for Apache provide an API to set r->filename which will take care of updating finfo? yes, but you saw how quickly the thread died out when that idea was introduced... like most other threads on httdp-dev list, which were lucky at all to become a thread... yeah *sigh* Philippe has worked on it and he said that it won't work. See: http://marc.theaimsgroup.com/?l=apache-modperl-dev&m=104495193904477&w=2 I don't know if anything has changed since then. right I remember that (though I thought there was some discussion on it too). anyway, I can't bring myself to belive that we can map the request_rec to a class but we can't map apr_finfo_t. maybe it's my naivete speaking, though :) so, I'll give it a whirl and see what I an do. I, for one, miss $r->finfo activity, and would like to see _something_ in mp2. maybe an API that's different from 1.0: use Apache::Finfo (); my $finfo = $r->finfo; $finfo->update(stat $foo); $mtime = (stat _)[9]; $finfo->size(-s $bar); etc... Sure, that will work. Though you can't manipulate finfo struct directly with perl function, which is what mp1 did. well, maybe most of it will be read-only. then maybe we can provide access to apr_stat through a class method Apache::Finfo->stat or something. whatever the API, I'm sure it will take shape after the apr_finfo_t work. Moreover we must be careful what accessors are provided. e.g. struct apr_file_t *filehand; returns a filehandle, which is not FILE. Though it could be made suitable for manipulation with APR::PerlIO. right. as I see it, the most used aspects of finfo will be the stuff we used to do in 1.0, which was mostly file tests. any goodies like an already open filehandle would be cool (though I only see Win32 populating finfo.filehand - kudos to them :) stat() != IO in a sense that you would want to use IO tracing if some data that you print is getting lost or corrupted. You would want to use some other tracing if you get the filestamp wrong, no? I can see both sides. given the current options, I think IO makes more sense than the others, but I really don't care. or if you think a new designation is deserved that's fine too, though I don't know what else would go there. at any rate, I guess the decision is to hold off on this implementation and see what can be done with a direct mapping, right? --Geoff - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: updating r->finfo on $r->filename($newfile)
Geoffrey Young wrote: Philippe has worked on it and he said that it won't work. See: http://marc.theaimsgroup.com/?l=apache-modperl-dev&m=104495193904477&w=2 I don't know if anything has changed since then. right I remember that (though I thought there was some discussion on it too). anyway, I can't bring myself to belive that we can map the request_rec to a class but we can't map apr_finfo_t. maybe it's my naivete speaking, though :) I believe you are trying to compare beer with cranberry juice. request_rec is not used by perl, whereas perl wants finfo as returned by stat to work with. so, I'll give it a whirl and see what I an do. May I suggest that we discuss first what is to be done? Philippe has already spent a lot of time trying to do that... I, for one, miss $r->finfo activity, and would like to see _something_ in mp2. maybe an API that's different from 1.0: use Apache::Finfo (); my $finfo = $r->finfo; $finfo->update(stat $foo); $mtime = (stat _)[9]; $finfo->size(-s $bar); etc... Sure, that will work. Though you can't manipulate finfo struct directly with perl function, which is what mp1 did. well, maybe most of it will be read-only. then maybe we can provide access to apr_stat through a class method Apache::Finfo->stat or something. whatever the API, I'm sure it will take shape after the apr_finfo_t work. Before putting much thought to it, since we are so eager to provide 1:1 mapping of the C API, we should just provide the perl glue to the functions in the APR API plus accessors to those elements that have no functions. Moreover we must be careful what accessors are provided. e.g. struct apr_file_t *filehand; returns a filehandle, which is not FILE. Though it could be made suitable for manipulation with APR::PerlIO. right. as I see it, the most used aspects of finfo will be the stuff we used to do in 1.0, which was mostly file tests. any goodies like an already open filehandle would be cool (though I only see Win32 populating finfo.filehand - kudos to them :) that could be an incosistency thing in apr lib. Not once someone implements a new thing or fixes a bug on one platform but won't sync other platforms because ... stat() != IO in a sense that you would want to use IO tracing if some data that you print is getting lost or corrupted. You would want to use some other tracing if you get the filestamp wrong, no? I can see both sides. given the current options, I think IO makes more sense than the others, but I really don't care. or if you think a new designation is deserved that's fine too, though I don't know what else would go there. what it really does, is manipulating an internal Apache struct, hence I suggested to have a tracing option which will show only traces that affect Apache internal structs. e.g. tracing the mod of document_root sounds like a good example which will fit the MP_TRACE_a category at any rate, I guess the decision is to hold off on this implementation and see what can be done with a direct mapping, right? More or less, yes. __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: updating r->finfo on $r->filename($newfile)
anyway, I can't bring myself to belive that we can map the request_rec to a class but we can't map apr_finfo_t. maybe it's my naivete speaking, though :) I believe you are trying to compare beer with cranberry juice. request_rec is not used by perl, whereas perl wants finfo as returned by stat to work with. so, I'll give it a whirl and see what I an do. May I suggest that we discuss first what is to be done? Philippe has already spent a lot of time trying to do that... hmm. maybe I'm just not understanding stuff. I can see where it would be hard to make this work my $size = -s $r->finfo like it did in 1.0. but I don't see how this would be too hard my $size = $r->finfo->csize while it's not as nifty as 1.0, and it wouldn't have the cached _ filehandle, it seems that using apache's cached stat information would still be more efficient that a full call to -s $r->filename. or are we just not taking about the same thing here? Before putting much thought to it, since we are so eager to provide 1:1 mapping of the C API, we should just provide the perl glue to the functions in the APR API plus accessors to those elements that have no functions. I don't understand this. do you mean complete missing parts of APR::? I haven't looked at APR too closely, but yeah, if there are missing parts that would be a good thing to do :) I guess I'm having a fairly unclear day :) I can see both sides. given the current options, I think IO makes more sense than the others, but I really don't care. or if you think a new designation is deserved that's fine too, though I don't know what else would go there. what it really does, is manipulating an internal Apache struct, hence I suggested to have a tracing option which will show only traces that affect Apache internal structs. e.g. tracing the mod of document_root sounds like a good example which will fit the MP_TRACE_a category ok, MP_TRACE_a it is, then. actually, I kind of like it - if we use it for places where we add logic behind what would otherwise be raw ap* calls, that would be very nice to have. cool. --Geoff - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: updating r->finfo on $r->filename($newfile)
Geoffrey Young wrote: anyway, I can't bring myself to belive that we can map the request_rec to a class but we can't map apr_finfo_t. maybe it's my naivete speaking, though :) I believe you are trying to compare beer with cranberry juice. request_rec is not used by perl, whereas perl wants finfo as returned by stat to work with. so, I'll give it a whirl and see what I an do. May I suggest that we discuss first what is to be done? Philippe has already spent a lot of time trying to do that... hmm. maybe I'm just not understanding stuff. I can see where it would be hard to make this work my $size = -s $r->finfo like it did in 1.0. but I don't see how this would be too hard my $size = $r->finfo->csize while it's not as nifty as 1.0, and it wouldn't have the cached _ filehandle, it seems that using apache's cached stat information would still be more efficient that a full call to -s $r->filename. Of course. I didn't say not. You just won't be able to use perl's API for that, but instead using APR API, so instead of saying: -r $r->finfo && -w _ ; users will have to say: $r->finfo->perms eq 'r' && $r->finfo->perms eq 'w' or whatever the accessor API is (will be). The stat struct is cached but on the apache side. or are we just not taking about the same thing here? Yup, we are talking about the same thing. I just thought that you said you will try to provide the mapping (i.e. provide a function which will convert apr_finfo_t to finfo). Before putting much thought to it, since we are so eager to provide 1:1 mapping of the C API, we should just provide the perl glue to the functions in the APR API plus accessors to those elements that have no functions. I don't understand this. do you mean complete missing parts of APR::? I haven't looked at APR too closely, but yeah, if there are missing parts that would be a good thing to do :) Neither I have looked, I hoped that finfo will somehow magically work in the future ;) I guess I'm having a fairly unclear day :) foggy ;) I can see both sides. given the current options, I think IO makes more sense than the others, but I really don't care. or if you think a new designation is deserved that's fine too, though I don't know what else would go there. what it really does, is manipulating an internal Apache struct, hence I suggested to have a tracing option which will show only traces that affect Apache internal structs. e.g. tracing the mod of document_root sounds like a good example which will fit the MP_TRACE_a category ok, MP_TRACE_a it is, then. actually, I kind of like it - if we use it for places where we add logic behind what would otherwise be raw ap* calls, that would be very nice to have. cool. cool++ -- __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: early perl startup in vhost on win32
Steve Hay wrote: At least I have found a sure way to verify that a segfault is caused by the wrong context. When you get a core trace where a Perl_ call, passing interpreter argument (my_perl on Unix, interpreter on win32), is followed by another Perl_ call, which doesn't pass this argument, go that that frame with the latter call and issue (gdb) p PL_curinterp if it doesn't match the interepreter (or my_perl) argument from the call one frame higher, you know what the problem is. In your trace: VMem::Free(void * 0x00acea1c) line 208 + 3 bytes CPerlHost::Free(void * 0x00acea1c) line 59 + 34 bytes PerlMemFree(IPerlMem * 0x00262434, void * 0x00acea1c) line 302 Perl_safesysfree(void * 0x00acea1c) line 143 + 26 bytes (gdb) p PL_curinterp Perl_sv_clear(interpreter * 0x012aff6c, sv * 0x013a1b3c) line 5198 + 13 bytes (gdb) up (gdb) p interpreter if the two are not the same, the problem is clear. PL_curinterp is a true global variable, so it's impossible to maintain it per interpreter. The next step is to figure out how to set the perl context every time we select a new interepreter without incurring too much overhead and encapsulate this function together with the selector code so not to clutter the code and prevent forgetting to set the context in the newly added code. I will keep you posted. __ Stas BekmanJAm_pH --> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
