Мой веб-сайт представляет собой приложение expressjs, которое упаковывается в образ докера и работает в AWS Fargate за ALB.Пользователи с большим количеством файлов cookie в домене (~ 7 КБ) сталкиваются с ошибкой 400 HTTP.Однако, если пользователь удаляет свои куки, проблема решается, по крайней мере, в течение нескольких дней, пока удаленные куки не будут переустановлены.Я являюсь одним поддоменом в этом домене, и у меня нет политического влияния для уменьшения количества файлов cookie или способа установки файлов cookie;Я работаю в большой компании.
Я устранил причину ошибки в ALB.Метрика CloudWatch, HTTPCode_ELB_4XX_Count равна 0, тогда как HTTPCode_Target_4XX_Count резко возрастает, когда я тестирую эту ошибку.
Моя диагностическая установка выглядит следующим образом: В моей учетной записи AWS для подготовки к производству я установил для среды DEBUG значение * на контейнере.Я также сократил проверку работоспособности целевой группы каждые 5 минут (для уменьшения трепетания) и уменьшил количество задач до 1 (для централизации журналов в одном потоке cwlog).Expressjs должен регистрировать любые входящие запросы, которые он направляет, с подробным описанием, аналогичным странице отладки Expressjs , однако абсолютно ничего не выводится в журнале.Это как если бы запрос не доходил до expressjs.Я подумал, может быть, я испортил настройку, но тестирование в режиме инкогнито приводит к выводу многих отладочных операторов.
Используя Postman, я скопировал заголовок cookie из Chrome CDT;Я продолжаю получать тот же результат 400 с заголовком Connection: close, включенным в ответ.Я использую модуль express-sessions, и если я удаляю cookie сеанса (connect.sid), запрос работает.Если я удаляю все куки, кроме connect.sid (сохраняя старое значение), запрос работает.Если я отправляю все файлы cookie, но обновляю connect.sid до значения, возвращаемого Set-Cookie, запрос работает.
Если я пробую те же тесты локально, используя docker-compose, я не смогу воспроизвести ошибку 400ответ на вопрос.Образы докера одинаковы как в docker-compose, так и в fargate.Оба используют postgres через модуль connect-pg-simple в качестве хранилища сеансов.Таким образом, потенциально может быть что-то в сетевом стеке AWS или среде выполнения AWS Fargate.
Соответствующие зависимости в package.json:
"connect-pg-simple": "^5.0.0",
"express": "^4.16.4",
"express-session": "^1.11.1",
"helmet": "^3.15.0",
"method-override": "^3.0.0",
"morgan": "^1.9.1",
"pg": "^7.6.1",
Вот некоторые выдержки из моего кода.Я включил другие установочные библиотеки, на случай, если они конфликтуют, хотя пропустил паспорт.
const express = require('express');
const compression = require('compression');
const helmet = require('helmet');
const methodOverride = require('method-override');
const pg = require('pg');
const session = require('express-session');
const pgSession = require('connect-pg-simple')(session);
const sessionStore = new pgSession({
pool: new pg.Pool()
});
const app = express();
app.use(methodOverride());
app.use(compression());
app.use(helmet({
// helmet settings omitted
}));
app.enable('trust proxy'); // Process X-Forwarded-* headers
app.use(session({
cookie: {
httpOnly: true,
secure: true
},
name: 'connect.sid',
resave: false,
saveUninitialized: true,
secret: 'some secret here',
store: sessionStore
}));
// rest of the code
Я был бы рад получить любые советы, указатели, предложения, уточняющие вопросы.Потратив на это несколько часов, я мог бы использовать новую перспективу.