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

Overriding HTTP verb VS. POST-REDIRECT-GET

Expand Messages
  • Unmesh Joshi
    Hi, Validating forms submitted by users and reporting back validations errors is a common requirement in HTTP web applications. POST-REDIRECT-GET is a commonly
    Message 1 of 4 , Mar 7, 2011
    • 0 Attachment
      Hi,

      Validating forms submitted by users and reporting back validations
      errors is a common requirement in HTTP web applications.
      POST-REDIRECT-GET is a commonly used pattern for this. But I recently
      saw an interesting piece of code, which forced me to think again about
      the basics.

      The code I am looking at, is actually overriding HttpServletRequest
      and oerriding 'getMethod' to change HTTP verb from POST to GET. then
      doing request forwarding.
      So for the forwarded resource its a GET request, even if from browser,
      its was a POST request.
      I see two problems with this,
      1. The response is still given to user agent as part of POST request.
      2. For web container, even if getMethod is overridden, its a POST
      request. (I do not know, if in the forwarded requests, web containers
      strictly use the request objects thats wrapped and do not use any of
      the internal information for that request)

      The advantage of this method, is that you do not need to persist
      information between redirects, So you do not need session or other
      persistence mechanism.

      Anyone else has seem this kind of idiom used in J2EE web applications?

      Thanks,
      Unmesh
    • Subbu Allamaraju
      None of this has any bearing on what is seen at the protocol level. At the protocol level, a POST is a POST. From your description it seems that this idiom is
      Message 2 of 4 , Mar 7, 2011
      • 0 Attachment
        None of this has any bearing on what is seen at the protocol level. At the protocol level, a POST is a POST.

        From your description it seems that this idiom is based on an incorrect understanding of the protocol.

        Subbu

        On Mar 7, 2011, at 12:07 AM, Unmesh Joshi wrote:

        > Hi,
        >
        > Validating forms submitted by users and reporting back validations
        > errors is a common requirement in HTTP web applications.
        > POST-REDIRECT-GET is a commonly used pattern for this. But I recently
        > saw an interesting piece of code, which forced me to think again about
        > the basics.
        >
        > The code I am looking at, is actually overriding HttpServletRequest
        > and oerriding 'getMethod' to change HTTP verb from POST to GET. then
        > doing request forwarding.
        > So for the forwarded resource its a GET request, even if from browser,
        > its was a POST request.
        > I see two problems with this,
        > 1. The response is still given to user agent as part of POST request.
        > 2. For web container, even if getMethod is overridden, its a POST
        > request. (I do not know, if in the forwarded requests, web containers
        > strictly use the request objects thats wrapped and do not use any of
        > the internal information for that request)
        >
        > The advantage of this method, is that you do not need to persist
        > information between redirects, So you do not need session or other
        > persistence mechanism.
        >
        > Anyone else has seem this kind of idiom used in J2EE web applications?
        >
        > Thanks,
        > Unmesh
        >
        >
        > ------------------------------------
        >
        > Yahoo! Groups Links
        >
        >
        >
      • Roy T. Fielding
        ... I don t see how that is responsive to the question. The server is changing a POST request inside the service handler to be a GET request so that the
        Message 3 of 4 , Mar 7, 2011
        • 0 Attachment
          On Mar 7, 2011, at 4:07 PM, Subbu Allamaraju wrote:
          > On Mar 7, 2011, at 12:07 AM, Unmesh Joshi wrote:
          >> Validating forms submitted by users and reporting back validations
          >> errors is a common requirement in HTTP web applications.
          >> POST-REDIRECT-GET is a commonly used pattern for this. But I recently
          >> saw an interesting piece of code, which forced me to think again about
          >> the basics.
          >>
          >> The code I am looking at, is actually overriding HttpServletRequest
          >> and oerriding 'getMethod' to change HTTP verb from POST to GET. then
          >> doing request forwarding.
          >> So for the forwarded resource its a GET request, even if from browser,
          >> its was a POST request.
          >> I see two problems with this,
          >> 1. The response is still given to user agent as part of POST request.
          >> 2. For web container, even if getMethod is overridden, its a POST
          >> request. (I do not know, if in the forwarded requests, web containers
          >> strictly use the request objects thats wrapped and do not use any of
          >> the internal information for that request)
          >>
          >> The advantage of this method, is that you do not need to persist
          >> information between redirects, So you do not need session or other
          >> persistence mechanism.
          >>
          >> Anyone else has seem this kind of idiom used in J2EE web applications?

          > None of this has any bearing on what is seen at the protocol level. At the protocol level, a POST is a POST.
          >
          > From your description it seems that this idiom is based on an incorrect understanding of the protocol.

          I don't see how that is responsive to the question. The server is
          changing a POST request inside the service handler to be a GET
          request so that the handler can do some funky chicken dance that
          has specific behavior within the current JDK.

          This is essentially the same thing that Apache httpd does when
          an internal content handler needs to perform an internal redirect
          to obtain some part of the content, such as with server-side
          includes being embedded in the POST response.

          REST plays no part in this because it is all behind the resource
          interface provided by the servlet engine. There are no constraints
          on POST, so changing the method to a safer one (like GET) is
          certainly not going to violate any of the client's expectations
          regarding their POST.

          It may be weird. It may be unreliable over time. But it is not
          inherently for or against RESTful interaction with the client.
          The reason for doing content handling in this manner is usually
          so that the internal request contains the same authentication
          information as the original request, thereby avoiding some
          security issues during request handling.

          ....Roy
        • Subbu Allamaraju
          ... Yes. However, as PRG is a protocol level pattern, my intent was to say that internal redirects/forwards won t help avoid state transfer through redirect. I
          Message 4 of 4 , Mar 7, 2011
          • 0 Attachment
            On Mar 7, 2011, at 7:00 PM, Roy T. Fielding wrote:

            > I don't see how that is responsive to the question. The server is
            > changing a POST request inside the service handler to be a GET
            > request so that the handler can do some funky chicken dance that
            > has specific behavior within the current JDK.
            >
            > This is essentially the same thing that Apache httpd does when
            > an internal content handler needs to perform an internal redirect
            > to obtain some part of the content, such as with server-side
            > includes being embedded in the POST response.
            >

            Yes. However, as PRG is a protocol level pattern, my intent was to say that internal redirects/forwards won't help avoid state transfer through redirect. I should've been more clear.

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