WebFluxTags :: uri возвращает неправильные теги - PullRequest
Новая
       6

WebFluxTags :: uri возвращает неправильные теги

0 голосов
/ 06 ноября 2019

Я не понимаю, почему этот метод реализован следующим образом: 

/**
 * Creates a {@code uri} tag based on the URI of the given {@code exchange}. Uses the
 * {@link HandlerMapping#BEST_MATCHING_PATTERN_ATTRIBUTE} best matching pattern if
 * available. Falling back to {@code REDIRECTION} for 3xx responses, {@code NOT_FOUND}
 * for 404 responses, {@code root} for requests with no path info, and {@code UNKNOWN}
 * for all other requests.
 * @param exchange the exchange
 * @return the uri tag derived from the exchange
 */
public static Tag uri(ServerWebExchange exchange) {
    PathPattern pathPattern = exchange.getAttribute(HandlerMapping.BEST_MATCHING_PATTERN_ATTRIBUTE);
    if (pathPattern != null) {
        return Tag.of("uri", pathPattern.getPatternString());
    }
    HttpStatus status = exchange.getResponse().getStatusCode();
    if (status != null) {
        if (status.is3xxRedirection()) {
            return URI_REDIRECTION;
        }
        if (status == HttpStatus.NOT_FOUND) {
            return URI_NOT_FOUND;
        }
    }
    String path = getPathInfo(exchange);
    if (path.isEmpty()) {
        return URI_ROOT;
    }
    return URI_UNKNOWN;
}

Мне кажется странным, что они используют exchange.getAttribute(HandlerMapping.BEST_MATCHING_PATTERN_ATTRIBUTE), в результате чего большая часть моего запроса возвращается с нулевым значением и по умолчанию принимает неизвестное значение. Однако при проверке обмена request.path содержит путь, который я хотел бы использовать.

Почему не используется request.path, который всегда имеет значение?

Как работает exchange.getAttribute(HandlerMapping.BEST_MATCHING_PATTERN_ATTRIBUTE). Я даже не понимаю, что он делает?

Почему некоторые мои запросы возвращают ноль для exchange.getAttribute(HandlerMapping.BEST_MATCHING_PATTERN_ATTRIBUTE), все контроллеры реализованы одинаково?

1 Ответ

1 голос
/ 06 ноября 2019

Когда запрос получен, он отображается на определенный обработчик, будь то метод @RequestMapping, функция маршрутизатора или что-то еще. Этот процесс отображения включает сопоставление с шаблоном пути. Шаблон пути, связанный с соответствующим обработчиком, сохраняется в BEST_MATCHING_PATTERN_ATTRIBUTE.

биржи. При создании тегов для обмена запросом-ответом BEST_MATCHING_PATTERN_ATTRIBUTE используется для предотвращения наличия у тега uriнеограниченный набор значений. Например, если запрос с URI /users/123456 сопоставлен с шаблоном /users/{id}, значение BEST_MATCHING_PATTERN_ATTRIBUTE будет равно /users/{id}. Если бы был использован путь запроса, вы бы получили разные значения тега uri для каждого пользователя. С миллионами пользователей вы получите миллионы значений для тега uri, которые могут нанести ущерб системе мониторинга.

Даже без миллионов пользователей злоумышленник может предпринять попытку отказа в обслуживании насистема мониторинга. Сделав миллионы запросов к /users/{id} с различными значениями для id, они могут заполнить систему мониторинга миллионами значений для тега uri.

К сожалению, я не могу с уверенностью сказать, почему некоторые запросыесть null BEST_MATCHING_PATTERN_ATTRIBUTE. Возможно, что нет подходящего обработчика и что ответ будет 404. Этот конкретный аспект вашего вопроса, вероятно, лучше рассмотреть в отдельном вопросе с сопровождающим примером.

...