Loading ...
Sorry, an error occurred while loading the content.

1190Re: ASP-Object in PerlAuth Handler

Expand Messages
  • Dr. Helmut Zeilinger
    May 8, 2003

      --On Mittwoch, 7. Mai 2003 11:35 -0700 Josh Chamas <josh@...> wrote:

      > Dr. Helmut Zeilinger wrote:
      > >
      >> One might argue, that if there is no CONTENT_LENGTH, the request POST
      >> data are also not fetched, and so my original problem does not exist.
      >> But it seems
      >> to be so, that only sometimes the POST data are fetched in the previous
      >> handler (???)
      > That is odd. I tend not to trust %ENV setup in other stages myself, and
      > to this effect, I will try to move away from using %ENV in the core
      > Apache::ASP for consistent behavior in earlier stages, and instead rely
      > on other things that are explicit like client HTTP headers.

      Probably a good idea to get all the information from the Apache-Request
      object itself.
      (like for ex. $r->headers_in ("content-length") etc.)

      >> For now i am using your workaround
      >> sub My::Auth::handler {
      >> local $ENV{CONTENT_LENGTH} = 0;
      >> my $ASP = Apache::ASP->new($r);
      > How about we create an explicit configration setting for this like:
      > sub My::Auth::handler {
      > $r->dir_config('RequestBinaryRead', 'Off);
      > my $ASP = Apache::ASP->new($r);
      > $r->dir_config('RequestBinaryRead', 'On');
      > ...
      > My only concern is that the %ENV hack may go away one day as it relies
      > on internal implementation. But if we wrap an explicit config around
      > it, I can make this work going forward. I thought about the caching
      > of Request or ASP objects, but that seems too messy to get right for now,
      > so I'd rather deal with the specific problem of handling POST data.
      > I might also be able to set the default for this value to be On only
      > for the PerlHandler / PerlResponseHandler, whereas other mod_perl callback
      > stages will have this turned off by default, so for you then it would
      > just work without explicitly setting the config. I think this would make
      > the most intuitive sense, to have POST data only read during a PerlHandler
      > phase unless explicitly configured otherwise.

      I agree, that the solution with the 'RequestBinaryRead' config parameter
      would be
      much better than the %ENV way, because one does not have to rely on the
      "internal" ASP
      code, rather than on an "official" config parameter.

      Setting the 'RequestBinaryRead' to 'Off' as default value in an other
      mod_perl handler than the
      response handler would be ok, but there might be users, who need the post
      data in that handler
      (for what reason ever) and are expecting it to work as "usual". Anyway, i
      would always prefere
      to set this parameter expilcitly, because then i am independend of any
      change of the default

      Of course i agree, that caching of the ASP object would be the most elegant
      and effective way, because
      work that has once been done in a previous handler need not be done again.
      But i can imagine, that is
      much work to get rid of the %ENV dependency (and possibly other things to
      make this work safely).
      But in principal the $r->pnotes way to store the ASP object should work. Of
      course there may be other
      ways to store and retreive this object during one request.

      In any case, as you pointed out, before reusing the ASP object, it should
      be checked against changes
      (e.g. filename etc.), and in case, being readjusted or destroyed and newly



      To unsubscribe, e-mail: asp-unsubscribe@...
      For additional commands, e-mail: asp-help@...
    • Show all 7 messages in this topic