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:

HttpScmRequestHandler, HttpScmRequestHandlerModuleDescriptor

Field Summary

Fields

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

Method Summary

Modifier and Type	Method and 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 Detail

BITBUCKET_REALM

static final String BITBUCKET_REALM

Realm to be used in any Authentication challenges.

See Also:

Constant Field Values

Method Detail

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