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

$My::SOAP::Transport::CGI::POST_MAX = 100 * 1024

Expand Messages
  • aaron_of_montreal
    Hi all, I spent a bit of time over the weekend looking through the code for CGI-based SOAP servers for a way to implement a CGI.pm style POST_MAX flag. I ended
    Message 1 of 7 , Jan 21, 2002
    • 0 Attachment
      Hi all,

      I spent a bit of time over the weekend looking through the code for
      CGI-based SOAP servers for a way to implement a CGI.pm style POST_MAX
      flag.

      I ended up subclassing SOAP::Transport::HTTP::CGI and overriding the
      handle method. I mention it in case anyone else has also been trying
      to figure out how to do this.

      Comments and suggestions would be appreciated. Cheers,

      http://aaronland.net/src/perl/soap-lite/My-SOAP-Transport-CGI.pm
    • Duncan Cameron
      Not sure that it need to be this complicated. Simply comparing $ENV{ CONTENT_LENGTH } with the POST_MAX constant should be enough. The middle bit of the
      Message 2 of 7 , Jan 21, 2002
      • 0 Attachment
        Not sure that it need to be this complicated.
        Simply comparing $ENV{'CONTENT_LENGTH'} with the POST_MAX constant
        should be enough. The middle bit of the handle() method can be
        simplified to:

        $self->request(HTTP::Request->new(
        $ENV{'REQUEST_METHOD'} || '' => $ENV{'SCRIPT_NAME'},
        HTTP::Headers->new(map {(/^HTTP_(.+)/i ? $1 : $_) => $ENV{$_}} keys %ENV)
        ));

        if ($POST_MAX &&
        ($POST_MAX >= 0 && $ENV{'CONTENT_LENGTH'} > $POST_MAX)) {
        $self->make_fault($SOAP::Constants::FAULT_CLIENT, "Your message is too long!")
        } else {
        read(STDIN,$content,$ENV{'CONTENT_LENGTH'} || 0);
        $self->request->content($content);
        $self->SOAP::Transport::HTTP::Server::handle();
        }

        # carry on and do the printing to STDOUT

        Paul might be happy to make a change to the SOAP::Transport::HTTP::CGI
        class directly as it's so small.

        Regards,
        Duncan Cameron

        On 2002-01-21 aaron_of_montreal <aaron_of_montreal@...> wrote:
        >Hi all,
        >
        >I spent a bit of time over the weekend looking through the code for
        >CGI-based SOAP servers for a way to implement a CGI.pm style POST_MAX
        >flag.
        >
        >I ended up subclassing SOAP::Transport::HTTP::CGI and overriding the
        >handle method. I mention it in case anyone else has also been trying
        >to figure out how to do this.
        >
        >Comments and suggestions would be appreciated. Cheers,
        >
        >http://aaronland.net/src/perl/soap-lite/My-SOAP-Transport-CGI.pm
        >
      • aaron_of_montreal
        ... [ apologies if this is a second post; the last one appears to have been sucked into the vortex...?! ] That s what I thought, originally, but decided to err
        Message 3 of 7 , Jan 21, 2002
        • 0 Attachment
          --- In soaplite@y..., Duncan Cameron <dcameron@b...> wrote:
          > Not sure that it need to be this complicated.
          > Simply comparing $ENV{'CONTENT_LENGTH'} with the POST_MAX constant
          > should be enough. The middle bit of the handle() method can be
          > simplified to:

          [ apologies if this is a second post; the last one appears to have
          been sucked into the vortex...?! ]

          That's what I thought, originally, but decided to err on the side of
          paranoia :

          "The Content-length header specifies the length of the data (in bytes)
          that is returned by the client-specified URL. Due to the dynamic
          nature of some requests, the Content-length is sometimes unknown, and
          this header might be omitted." [1]

          [1] http://oreilly.com/openbook/webclient/ch03.html#38198
        • Paul Kulchenko
          Hi, Aaron! ... From the context it seems like this text applies to server side, rather than to client side, so Duncan s code should be sufficient in most if
          Message 4 of 7 , Jan 21, 2002
          • 0 Attachment
            Hi, Aaron!

            --- aaron_of_montreal <aaron_of_montreal@...> wrote:
            > That's what I thought, originally, but decided to err on the side
            > of paranoia :
            >
            > "The Content-length header specifies the length of the data (in
            > bytes)
            > that is returned by the client-specified URL. Due to the dynamic
            > nature of some requests, the Content-length is sometimes unknown,
            > and this header might be omitted." [1]
            From the context it seems like this text applies to server side,
            rather than to client side, so Duncan's code should be sufficient in
            most if not all cases.

            The only problem that I currently have is whether I should return
            HTTP error (for example: "413 Request Entity Too Large") or SOAP
            fault. I can also generate "411 Length Required" when there is no
            Content-length header.

            Best wishes, Paul.

            __________________________________________________
            Do You Yahoo!?
            Send FREE video emails in Yahoo! Mail!
            http://promo.yahoo.com/videomail/
          • Duncan Cameron
            Thinking about this a bit more, I m not sure of the usefulness of checking content-length at this stage - it may be too late. What s the motivation? To stop
            Message 5 of 7 , Jan 21, 2002
            • 0 Attachment
              Thinking about this a bit more, I'm not sure of the usefulness of
              checking content-length at this stage - it may be too late.

              What's the motivation? To stop deliberate attempts to overload/crash
              the SOAP application? By the time the CGI application runs, the http
              server has probably read all the request anyway. Maybe it's the http
              server which needs to have limit applied?

              However I notice that CGI.pm has a similar idea, $CGI::POST_MAX,
              so perhaps it's a sound idea.

              Regards,
              Duncan Cameron

              On 2002-01-21 Paul Kulchenko <paulclinger@...> wrote:
              >Hi, Aaron!
              >
              >--- aaron_of_montreal <aaron_of_montreal@...> wrote:
              >> That's what I thought, originally, but decided to err on the side
              >> of paranoia :
              >>
              >> "The Content-length header specifies the length of the data (in
              >> bytes)
              >> that is returned by the client-specified URL. Due to the dynamic
              >> nature of some requests, the Content-length is sometimes unknown,
              >> and this header might be omitted." [1]
              >>From the context it seems like this text applies to server side,
              >rather than to client side, so Duncan's code should be sufficient in
              >most if not all cases.
              >
              >The only problem that I currently have is whether I should return
              >HTTP error (for example: "413 Request Entity Too Large") or SOAP
              >fault. I can also generate "411 Length Required" when there is no
              >Content-length header.
              >
              >Best wishes, Paul.
              >
            • Paul Kulchenko
              Hi, Duncan! ... the ... No, server shouldn t read all the request at this point. In most cases it ll just redirect STDIN/STDOUT, so CGI application will get
              Message 6 of 7 , Jan 21, 2002
              • 0 Attachment
                Hi, Duncan!

                --- Duncan Cameron <dcameron@...> wrote:
                > What's the motivation? To stop deliberate attempts to
                > overload/crash
                > the SOAP application? By the time the CGI application runs, the
                > http server has probably read all the request anyway. Maybe it's
                the
                > http server which needs to have limit applied?
                No, server shouldn't read all the request at this point. In most
                cases it'll just redirect STDIN/STDOUT, so CGI application will get
                the request by reading its STDIN.

                > However I notice that CGI.pm has a similar idea, $CGI::POST_MAX,
                > so perhaps it's a sound idea.
                Yes, because it's CGI app's responsibility to read and handle the
                request.

                Best wishes, Paul.

                __________________________________________________
                Do You Yahoo!?
                Send FREE video emails in Yahoo! Mail!
                http://promo.yahoo.com/videomail/
              • aaron_of_montreal
                ... If you follow the examples set by CGI.pm and the Contentious Issues section of the SOAP book, wouldn t you do both? e.g. return the fault, but set the
                Message 7 of 7 , Jan 21, 2002
                • 0 Attachment
                  --- In soaplite@y..., Paul Kulchenko <paulclinger@y...> wrote:

                  > The only problem that I currently have is whether I should return
                  > HTTP error (for example: "413 Request Entity Too Large") or SOAP

                  If you follow the examples set by CGI.pm and the "Contentious Issues"
                  section of the SOAP book, wouldn't you do both? e.g. return the fault,
                  but set the reponse code to 413.

                  > fault. I can also generate "411 Length Required" when there is no
                  > Content-length header.

                  I guess my preference would be to actually read/count the bytes since
                  the Content-length header could, arguably, be tweaked and not match
                  the actual size of the request.

                  If returning a 411 code is the "Right Thing" to do then I can deal but
                  I am more concerned with how much data is really being read from
                  STDIN.

                  Cheers,
                Your message has been successfully submitted and would be delivered to recipients shortly.