Details

    • Type: Improvement Improvement
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: I/O
    • Labels:
      None

      Description

      Section 9.7.2 describes a set of request attributes that contain the path values of the original request, so that they may be accessed by a servlet called as a result of a AsyncContext.dispatch(...)

      However, this implies that these attributes are only set after a AsyncContext.dispatch(...), which means that they are not available to a thread that might be acting as part of a startAsync().... AsyncContext.complete() pattern.

      Note that a thread cannot access the original request paths via AsyncContext.getRequest().getServletPath() because the value returned from that can be affected by forwards that happen before and/or after the startAsync call, or even a forward after an async dispatch. The path methods are inherently volatile.

      I think that the ASYNC request parameters should be set when startAsync is called, so that those values are available for the entire async life cycle and not only during async dispatch.

        Activity

        Hide
        gregwilkins added a comment -

        very late response.

        I don't see why a request can't be forwarded after async is started. It would be strange way to handle a request, but I see no reason for it to be prohibited.

        But even if it can't be forwarded, it can be return from previous forwards after startAsync, so the values returned by the request.getXxx() methods will be volatile if access from an asynchronous thread.

        Hence I believe the request attributes are the best way to obtain path information as they are immutable once set and thus thread safe.

        Show
        gregwilkins added a comment - very late response. I don't see why a request can't be forwarded after async is started. It would be strange way to handle a request, but I see no reason for it to be prohibited. But even if it can't be forwarded, it can be return from previous forwards after startAsync, so the values returned by the request.getXxx() methods will be volatile if access from an asynchronous thread. Hence I believe the request attributes are the best way to obtain path information as they are immutable once set and thus thread safe.
        Hide
        rstoyanchev added a comment -

        can be affected by forwards that happen before and/or after the startAsync call

        Greg, the impression I got from SERVLET_SPEC-41 is that forwards cannot happen after a call to startAsync or are you referring to a different scenario?

        Show
        rstoyanchev added a comment - can be affected by forwards that happen before and/or after the startAsync call Greg, the impression I got from SERVLET_SPEC-41 is that forwards cannot happen after a call to startAsync or are you referring to a different scenario?
        Hide
        gregwilkins added a comment -

        Note also that the language used in this section could be improved, where it says:

        The values of these attributes must be equal to the return values of the
        HttpServletRequest methods getRequestURI, getContextPath, getServletPath,
        getPathInfo, getQueryString respectively, invoked on the request object passed to
        the first servlet object in the call chain that received the request from the client.

        A request might never be passed to a servlet as it might be handled entirely by filters, or the first servlet object might be changed by a filter doing a dispatch.

        Show
        gregwilkins added a comment - Note also that the language used in this section could be improved, where it says: The values of these attributes must be equal to the return values of the HttpServletRequest methods getRequestURI, getContextPath, getServletPath, getPathInfo, getQueryString respectively, invoked on the request object passed to the first servlet object in the call chain that received the request from the client. A request might never be passed to a servlet as it might be handled entirely by filters, or the first servlet object might be changed by a filter doing a dispatch.

          People

          • Assignee:
            Unassigned
            Reporter:
            gregwilkins
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated: