С точки зрения предполагаемой цели кодов ошибок HTTP, я бы определенно пойти с 403 Forbidden, потому что страница существует (404 выходит), но пользователь запрещено к нему доступ сейчас (и это ограничение не связано с конфликтом ресурсов, например, с одновременной модификацией, но из-за состояния учетной записи пользователя, то есть, по моему мнению, тоже 409). Другим разумным вариантом, основанным на его намеренной цели, могло быть 401, но, как уже отмечалось в его комментарии, этот код запускает некоторые, если не все, браузеры для отображения диалогового окна входа в систему, поскольку это подразумевает, что использование стандартного механизма веб-аутентификации может решить проблему. Таким образом, это определенно не будет вариантом для вас здесь.
Две вещи кажутся немного «misfitting» в описании 403, так что позвольте мне обратиться к ним:
- Авторизация не поможет ...: Это говорит только о механизме авторизации внутри HTTP протокол и предназначен для различения 403 с 401.Этот оператор не применяется к какой-либо форме пользовательского авторизации или управления сеансом.
- ... запрос НЕ ДОЛЖЕН повториться ...: Запрос должен всегда отображаться в контексте сеанса, поэтому, если контекст сеанса пользователя изменяется (он открывает функцию), а затем он пытается получить доступ к тот же ресурс, то есть другой запрос, т. е. нет никакого нарушения этого предложения.
Конечно, вы также можете определить свой собственный код ошибки, но поскольку он, вероятно, не будет зарезервирован каким-либо официальным способом, нет никакой гарантии, что какой-либо производитель браузеров не намеренно или случайно не использует точно этот код запускает определенное (отладочное) действие. Это маловероятно, но не запрещено.
418 может быть в порядке, тоже. :)
Конечно, если вы хотите конкретно скрывать потенциальную доступность функций, вы также можете решить использовать 404, так как это единственный способ не дать любопытным пользователям никаких намеков.
Теперь к вашему вопросу кэширования:
Ни один из этих кодов состояния (403, 404, 409, 418) должен триггерных браузер кэшировать страницу против вашей воли больше, чем любой другой. Проблема в том, что многие браузеры просто пытаются кэшировать все, как сумасшедшие, чтобы быть более быстрым. Оперы здесь хуже всего, на мой взгляд. Я много раз вытягивал свои волосы над этими вещами. СЛЕДУЕТ иметь возможность работать со всеми правильными настройками заголовка, но у меня были ситуации, когда либо браузер, либо сервер, либо какой-то промежуточный прокси решили игнорировать их и в любом случае сломать мою страницу.
Единственный надежный способ, который я нашел до сих пор, что абсолютно положительно гарантирует перезагрузку, заключается в добавлении параметра фиктивного запроса, например/fields? T = 29873, где 29873 - это номер, который уникален для каждого запроса, который вы делаете в любых возможных временных масштабах. На сервере, конечно, вы можете просто игнорировать этот параметр. Обратите внимание, что недостаточно просто начать с 1, когда ваш пользователь сначала откроет вашу страницу, а затем подсчитает следующие запросы, так как браузеры могут хранить кеш во всех перезагрузках страниц.
Я делаю веб-разработки в Java (как сервера и на стороне клиента с помощью GWT), и я использую этот код для создания фиктивных «номера»:
private static final char[] base64chars = "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz_.".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-адреса.
Надеюсь, это поможет.:)
Я не знаю правильного ответа, но следующее сообщение содержит несколько интересных аргументов: http://stackoverflow.com/questions/3297048/403-forbidden-vs-401-unauthorized-http-responses – RobJohnson
Почему бы не просто перенаправить на страницу, на которую им разрешено находиться? Также возможно показать всплывающее высказывание, что эта функция пока недоступна. –
Кстати, '401 Unauthorized' будет плохой идеей, потому что этот код состояния предназначен только для HTTP-аутентификации, и браузеры обрабатывают этот код состояния специально. – nalply