С точки зрения назначения кодов ошибок HTTP, я бы определенно выбрал 403 Forbidden, потому что страница существует (404 отсутствует), но пользователю запрещен доступ к ней на данный момент (и это ограничение связано не с конфликтом ресурсов, например с одновременным изменением, а из-за статуса учетной записи пользователя, т.е. 409, по моему мнению, также отсутствует). Другим разумным вариантом, основанным на его предполагаемой цели, мог быть 401, но, как уже было отмечено в его комментарии, этот код запускает некоторые, если не все, браузеры для отображения диалогового окна входа в систему, поскольку это подразумевает, что использование стандартного механизма веб-аутентификации может решить проблему. Так что тут точно не ваш вариант.
Две вещи кажутся немного «неуместными» в описании 403, поэтому позвольте мне остановиться на них:
- Авторизация не поможет... Это говорит только о механизме авторизации внутри протокола HTTP и предназначено для того, чтобы отличить 403 от 401. Это утверждение не относится ни к какой форме пользовательской авторизации или управлению состоянием сеанса. .
- ...запрос НЕ ДОЛЖЕН повторяться...: Запрос всегда должен отображаться в контексте сеанса, поэтому, если контекст сеанса пользователя изменится (он разблокирует функцию), а затем повторит попытку доступ к тому же ресурсу, то есть другой запрос, т.е. нет нарушения этого предложения.
Конечно, вы также можете определить свой собственный код ошибки, но, поскольку он, вероятно, не будет зарезервирован каким-либо официальным способом, нет никакой гарантии, что какой-либо производитель браузера не собирается намеренно или случайно использовать именно этот код для запуска определенной ошибки. (отладочное) действие. Это маловероятно, но не запрещено.
Хотя 418 тоже может подойти. :)
Конечно, если вы хотите специально скрыть потенциальную доступность функций, вы также можете решить использовать 404, поскольку это единственный способ не давать любопытным пользователям никаких подсказок.
Теперь к вашей проблеме с кэшированием:
Ни один из этих кодов состояния (403, 404, 409, 418) не должен заставлять браузер кэшировать страницу против вашей воли в большей степени, чем любой другой. Проблема в том, что многие браузеры просто пытаются кэшировать все как сумасшедшие, чтобы быть очень быстрыми. На мой взгляд, Опера здесь самая худшая. Я много раз рвал на себе волосы из-за этих вещей. ДОЛЖНО быть возможно решить все это с правильными настройками заголовка, но у меня были ситуации, когда либо браузер, либо сервер, либо какой-то промежуточный прокси-сервер решили игнорировать их и все равно сломать мою страницу.
Единственный верный способ, который я нашел до сих пор, который абсолютно точно гарантирует перезагрузку, — это добавить фиктивный параметр запроса, такой как /fields?t=29873, где 29873 — это число, уникальное для каждого запроса, который вы делаете в любом, возможно, релевантном шкалы времени. На сервере, конечно, вы можете просто игнорировать этот параметр. Обратите внимание, что недостаточно просто начать с 1, когда ваш пользователь впервые открывает вашу страницу, а затем подсчитывать последующие запросы, поскольку браузеры могут сохранять кэш при перезагрузке страницы.
Я делаю свою веб-разработку на Java (как на стороне сервера, так и на стороне клиента, используя GWT), и я использую этот код для создания фиктивных «чисел»:
private static final char[] base64chars = "0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz_.".toCharArray();
private static int tagIndex = 0;
/**
* Generates a unique 6-character tag string that is guaranteed to not repeat
* for about 400 days, if this function is, on average, not called more often
* than twice every millisecond.
*
* @return the tag string
*/
public static String nowTag() {
int tag = (int) ((System.currentTimeMillis() >>> 5)); // adjust
char[] result = new char[6];
result[5] = base64chars[(tagIndex++) & 63];
result[4] = base64chars[tag & 63];
tag >>>= 6;
result[3] = base64chars[tag & 63];
tag >>>= 6;
result[2] = base64chars[tag & 63];
tag >>>= 6;
result[1] = base64chars[tag & 63];
tag >>>= 6;
result[0] = base64chars[tag & 63];
return new String(result);
}
Он использует системные часы в сочетании со счетчиком, чтобы иметь возможность предоставлять до двух гарантированных уникальных значений каждую мс. Возможно, вам не нужна эта скорость, поэтому вы можете свободно изменять >>> 5, который я пометил как «настроить», в соответствии с вашими потребностями. Если вы увеличите его на 1, ваша ставка уменьшится в два раза, а временной диапазон вашей уникальности удвоится. Так, например, если вместо этого поставить >>> 8, можно генерировать примерно 1 значение каждые 4 мс, и значения не должны повторяться в течение 3200 дней. Конечно, эта гарантия того, что значения не будут повторяться, исчезнет, если пользователь испортит системные часы. Но поскольку эти значения не генерируются последовательно, очень маловероятно, что вы нажмете одно и то же число дважды. Код генерирует 6-символьную текстовую строку (base64), а не десятичное число, чтобы URL-адреса были как можно короче.
Надеюсь это поможет. :)
person
Markus A.
schedule
26.02.2013
401 Unauthorizedбыло бы плохой идеей, потому что этот код состояния предназначен только для HTTP-аутентификации, и браузеры обрабатывают этот код состояния специально. - person nalply schedule 23.02.2013