dimasmagadan: в книжке речь о 2007 годе (сама книжка от 2009), то есть на сегодняшний день это непозволительно устаревшая информация.
Вопрос pxx задан более трех лет назад, это очень и очень давно по меркам развития интернета.
На хамство позвольте не отвечать, спасибо и до свидания.
dimasmagadan: лолшто? Спецификацию на не совсем честные приемчики в войне браузеров? :)
А, вы просто вопрос не дочитали. Так вот, вкратце: очень похоже что "некоторым прокси-сервером" в данном случае является сам браузер. Потому что на сервер он НЕ ХОДИТ, а дает закэшированный ранее ответ. Несмотря на изменившийся запрос, ага.
Алексей: да, сейчас спасаюсь именно POST, но тут возникает сразу две проблемы:
- это не отвечает стандарту REST
- используемый в API механизм не умеет делать внутренний рероутинг с методом, отличным от GET.
Я не понимаю, откуда появилась дробь... API честно отдает 10 секунд, во всех ответах видны эти 10, а вот один поймал вот с таким чудом.
В API эти 10 сек захардкожены на время экспериментов, со стороны сервера эта подляна исключена.
Добрый день
Приведенный вами набор из трех устаревших директив не работает уже несколько лет. Я сталкивался с этим примерно в 2012, тогда проблему удалось решить добавлением левого параметра в строку запроса (как-то ?nocache=blablabla). Сейчас война браузеров вышла на новый виток и по всей видимости нужно придумывать что-то новое.
Вчера я еще раз убедился в этом, вы можете это повторить. Укажите Cache-Control:max-age=0, must-revalidate, no-cache и 100% таких запросов будут закэшированы как минимум в Safari и скорее всего в Chrome. Укажите вместо этого реальные Expires и Last-modified как в моем примере — и такие запросы будут кэшироваться куда реже.
В локалсторадже хранится timestamp последнего ответа, он добавляется к другим запросам.
В принципе не страшно если юзер получит обновление новостей на 10 минут позже. Главная жопа в том, что кешируются запросы на авторизацию (даже с добавленным рандомным параметром в виде timestamp), что приводит к полной невозможности работать.
Последние полчаса работает нормально, но думаю что ночью как обычно все начнется снова.
Сразу бросилось в глаза Cache-Control:max-age=0,19803810119629. На сервере выставлено 10 сек, у других таких же запросов (они периодические) так и есть 10 сек, а у одного вот такое.
Алексей: Частота обращений — 5...15 секунд.
timestamp добавляется при каждом составлении запроса. Он точно разный, я его в нетворке вижу :)
Про замену nocache и собственно таймштампа на черт-те что уже была мысль: делал два параметра, в одном таймштамп, в другом рандомная строка - без толку. Правда второй параметр тоже содержал слово cache, может быть поэтому и был проигнорирован... Неужели все так по-скотски :(
Super User: тут скорее фишка в том "кто на что учился". Если вы владеете фотошопом/иллюстратором лучше чем галпом — вам и в голову такое не придет, поверьте.
lavan: информация не соответсвует действительнотсти.
Работаю с PP не так давно, с 2010 года, возможно у вас опыта побольше, но:
Способ конвертации в РР устанавливается в кабинете.
Активно катаюсь по странам, имею два аккаунта, захожу в любой из любой страны — проблем нет.
Единственный раз понадобился скан utility bill для не-российского аккаунта. Для российского — только подтверждение паспорта, но росеян без паспорта даже в туалет теперь не пускают.
Оплачиваю что-нибудь практически каждый день, во время скачков курсов ни одной проблемы не было.
Кстати собственно moment.js и выводит время для наблюдателя. Но я не нашел в его доке способа показывать "оригинальное" время, он упорно перегоняет все в таймзону наблюдателя.
Вот пользователь из Asia/Yekaterinburg оставил в базе свою метку 1456415507234 и она при любых комбинациях показывается как Europe/Moscow. Что нужно сделать в moment.js чтобы он перестал умничать?
Строку дороже хранить и сложнее форматировать. Какие у нее преимущества?
