Package com.atlassian.bitbucket.scm.http

Interface HttpScmRequest

All Superinterfaces:
ScmRequest
public interface HttpScmRequest extends ScmRequest
Handles an HTTP request from an SCM client (e.g. a git clone or git pull)
See Also:

  • Field Summary

    Fields
    Modifier and Type
    Field
    Description
    static final String
    BITBUCKET_REALM
    Realm to be used in any Authentication challenges.

  • Method Summary

    Modifier and Type
    Method
    Description
    default boolean
    isAsyncSupported()
    Allows requests to indicate whether they support using Servlet 3's asynchronous execution.

    Methods inherited from interface com.atlassian.bitbucket.scm.ScmRequest

    getRepository, handleRequest, isWrite, sendError

  • Field Details

    • BITBUCKET_REALM

      static final String BITBUCKET_REALM
      Realm to be used in any Authentication challenges.
      See Also:

  • Method Details

    • isAsyncSupported

      default boolean isAsyncSupported()
      Allows requests to indicate whether they support using Servlet 3's asynchronous execution.

      In general, synchronous and asynchronous execution behave similarly. The primary difference is that asynchronous execution is moved to a background executor thread where synchronous execution takes place directly on a servlet container (e.g. Tomcat) thread. As a result, most implementations will not need to do anything specific to "support" asynchronous execution.

      Asynchronous execution does not mean non-blocking execution. Asynchronous execution can still perform blocking reads and writes during processing. However, in order for a request to use Servlet 3.1's ReadListener and WriteListener to perform non-blocking handling, it must be running asynchronously. (This is a restriction from the Servlet spec, not one imposed by this SPI.)

      Warning: Just because a request supports asynchronous execution does not guarantee it will be invoked asynchronously. Implementors must check ServletRequest.isAsyncStarted() to determine whether the request is running asynchronously, and the implementation must still support synchronous execution. This restriction stems from the pluggable nature of the filter chain. Apps are free to register custom filters in the chain, applied to any URL (including the /scm hosting URL), and they can mark their filters as not supporting async. When that happens, it prevents requests from executing asynchronously.

      Returns:
      true if this request can be executed asynchronously; otherwise, false to require standard synchronous execution
      Since:
      7.4