Source code
package org.springframework.web.socket.sockjs.transport.handler;
import java.io.IOException;
import java.nio.charset.StandardCharsets;
import java.util.regex.Pattern;
import org.jspecify.annotations.Nullable;
import org.springframework.http.MediaType;
import org.springframework.http.server.ServerHttpRequest;
import org.springframework.http.server.ServerHttpResponse;
import org.springframework.util.MultiValueMap;
import org.springframework.util.StringUtils;
import org.springframework.web.socket.WebSocketHandler;
import org.springframework.web.socket.sockjs.SockJsException;
import org.springframework.web.socket.sockjs.frame.SockJsFrame;
import org.springframework.web.socket.sockjs.frame.SockJsFrameFormat;
import org.springframework.web.socket.sockjs.transport.SockJsSession;
import org.springframework.web.socket.sockjs.transport.SockJsSessionFactory;
import org.springframework.web.socket.sockjs.transport.session.AbstractHttpSockJsSession;
import org.springframework.web.util.UriComponentsBuilder;
import org.springframework.web.util.UriUtils;
/**
* Base class for HTTP transport handlers that push messages to connected clients.
*
* @author Rossen Stoyanchev
* @since 4.0
*/
public abstract class AbstractHttpSendingTransportHandler extends AbstractTransportHandler
implements SockJsSessionFactory {
/**
* Pattern for validating callback parameter values.
*/
private static final Pattern CALLBACK_PARAM_PATTERN = Pattern.compile("[0-9A-Za-z_.]*");
@Override
public final void handle(ServerHttpRequest req, ServerHttpResponse res,
WebSocketHandler ws, SockJsSession ws2) throws SockJsException {
AbstractHttpSockJsSession sock = (AbstractHttpSockJsSession) ws2;
// https://github.com/sockjs/sockjs-client/issues/130
// sockJsSession.setAcceptedProtocol(protocol);
// Set content type before writing
res.getHeaders().setContentType(get());
handle2(req, res, sock);
}
protected void handle2(ServerHttpRequest req2, ServerHttpResponse res2,
AbstractHttpSockJsSession sock2) throws SockJsException {
if (sock2.isNew()) {
if (logger.isDebugEnabled()) {
logger.debug(req2.getMethod() + " " + req2.getURI());
}
sock2.handleInitialRequest(req2, res2, get2(req2));
}
else if (sock2.isClosed()) {
if (logger.isDebugEnabled()) {
logger.debug("Connection already closed (but not removed yet) for " + sock2);
}
write(SockJsFrame.closeFrameGoAway(), req2, res2, sock2);
}
else if (!sock2.isActive()) {
if (logger.isTraceEnabled()) {
logger.trace("Starting " + getTransportType() + " async request.");
}
sock2.handleSuccessiveRequest(req2, res2, get2(req2));
}
else {
if (logger.isDebugEnabled()) {
logger.debug("Another " + getTransportType() + " connection still open for " + sock2);
}
write(SockJsFrame.closeFrameAnotherConnectionOpen(), req2, res2, sock2);
}
}
private void write(SockJsFrame fra, ServerHttpRequest req3, ServerHttpResponse res3,
AbstractHttpSockJsSession sock3) {
String formatted = get2(req3).format(fra);
try {
res3.getBody().write(formatted.getBytes(SockJsFrame.CHARSET));
}
catch (IOException ex) {
throw new SockJsException("Failed to send " + formatted, sock3.getId(), ex);
}
}
protected abstract MediaType get();
protected abstract SockJsFrameFormat get2(ServerHttpRequest req4);
protected final @Nullable String get3(ServerHttpRequest req5) {
String que = req5.getURI().getQuery();
MultiValueMap<String, String> par = UriComponentsBuilder.newInstance().query(que).build().getQueryParams();
String val = par.getFirst("c");
if (!StringUtils.hasLength(val)) {
return null;
}
String res4 = UriUtils.decode(val, StandardCharsets.UTF_8);
return (CALLBACK_PARAM_PATTERN.matcher(res4).matches() ? res4 : null);
}
}
Run 1
This code is extremely difficult to read due to terrible naming conventions. Methods are named 'get', 'get2', 'get3', and 'handle2'; parameters are 'req', 'req2', 'req3', 'req4', 'sock', 'ws2', etc. These opaque names destroy clarity of intent and reading flow. While the code is fairly flat and concise, the action granularity is mostly one per line, and the structure is okay, the naming makes it impossible to understand the purpose without extensive reverse-engineering. The 'get' methods are particularly confusing: one returns a MediaType, another a SockJsFrameFormat, and another a @Nullable String. This is a textbook case of unreadable code despite a logical package structure.
Run 2
The code suffers from severe readability issues. Generic, non-descriptive method names like 'handle2', 'get', 'get2', and 'get3' completely obscure the code's intent, violating the 'Clarity of intent' and 'Reading flow' criteria. Similarly, sequentially named parameters (req, req2, req3, sock2, res4) make the logic difficult to follow and are highly ambiguous. The class also violates the Single Responsibility Principle; it is a transport handler, session factory, and utility for parsing callback parameters, leading to a tangled 'Code structure'. While the use of early returns in the main flow avoids deep nesting, the confusing naming and mixed responsibilities negate that benefit. Consequently, the code is unnecessarily hard to parse, requiring constant mental mapping of variables and methods to their actual functions.
Run 3
The code is poorly readable due to vague method names (get, get2, get3), confusing sequential parameter names (req2, res2, sock2), and inconsistent return types (MediaType vs SockJsFrameFormat vs String). It has one method that combines multiple operations (validation, decoding, pattern matching), moderate nesting in conditionals, and poor reading flow. Positives include reasonable overall structure, single responsibility in some methods, and explanatory debug logs. However, the vague naming and unclear intent make the code difficult to understand without deep context.
Run 1
Code Structure: Methods separate request handling, frame writing, and callback validation logically. Nesting: The state-based conditional chain is straightforward, with only shallow nested logging checks. Clarity of intent: The main weakness is vague naming such as get, get2, get3, handle2, ws2, and res4, which obscures responsibilities and forces readers to infer meaning from types and usage. Code length: Generally concise, although repeated logging guards and obsolete commented-out code add noise. Action granularity: Most statements perform one action per line; the chained query-parsing expression is somewhat dense. Reading flow: The progression from entry point to state handling and helpers is natural, but numbered identifiers and minimally documented abstract methods interrupt comprehension.
Run 2
Code Structure: Methods logically separate request handling, frame writing, and callback validation, though generic method names obscure those boundaries. Nesting: Mostly shallow, with a manageable conditional chain and nested logging checks. Clarity of intent: The main weakness is ambiguous naming such as get, get2, get3, handle2, ws2, and res4; types and API calls provide context but require extra inference. Code length: Reasonably concise, although repeated logging guards and obsolete commented-out code add clutter. Action granularity: Most statements perform one action per line, but chained query parsing compresses several operations into one statement. Reading flow: Session-state branches follow a natural sequence, and formatting is consistent within methods; dense imports, numbered identifiers, and uneven blank-line spacing reduce scanability. Overall, the control flow is readable, but poor naming significantly weakens comprehension.
Run 3
Code Structure: Responsibilities are logically separated into request dispatch, session-state handling, frame writing, and callback extraction. Nesting: Mostly shallow, with logging checks adding only one level inside state branches. Clarity of intent: The principal weakness is ambiguous naming such as get, get2, get3, handle2, ws2, and res4; readers must inspect implementations or infer types to understand their roles. Code length: Reasonably concise, though repeated logging checks and obsolete commented-out code add noise. Action granularity: Statements generally perform one action per line, although callback parsing uses a long chained expression. Reading flow: Session-state branches follow a natural progression, and formatting is consistent, but numbered variable names and opaque helper methods interrupt comprehension. Overall, sound organization and limited nesting are undermined by poor naming.