[html/js]Последовательное выполннение запросов
мб, прежде, чем отправлять куку юзеру, похранить её на сервере и читать/писать во временную переменную?
Честно говоря не понял.
Для ясности - каждый запрос скорее всего обрабатывается другим инстансом сервера на другом боксе. Единственная возможность отослать куку - это в ответ на запрос. Но в связи с тем, что запрос несколько миллисекунд обрабатывается, сука-браузер успевает послать второй запрос.
Для ясности - каждый запрос скорее всего обрабатывается другим инстансом сервера на другом боксе. Единственная возможность отослать куку - это в ответ на запрос. Но в связи с тем, что запрос несколько миллисекунд обрабатывается, сука-браузер успевает послать второй запрос.
Ну так делайте так, чтобы не более 1 запроса на страницу было.
Это мера, на которую пойти невозможно
а, мб, вместо куков сессию использовать?
есть возможность править скриты на сервере?
если есть - правь их, что бы куки брались не в самом начале, а для каждого запроса отдельно...
Если нет доступа- то делай авторедирект после каждого запроса автоматом... типа что бы пользователь ниче не нажимал.... или один запрос на страницу...
А вообще - это надо же еще было додуматься до такой херни то....
Где это ? и что за запросы?
если есть - правь их, что бы куки брались не в самом начале, а для каждого запроса отдельно...
Если нет доступа- то делай авторедирект после каждого запроса автоматом... типа что бы пользователь ниче не нажимал.... или один запрос на страницу...
А вообще - это надо же еще было додуматься до такой херни то....
Где это ? и что за запросы?
Запросы - это запрос баннера. На странице может быть несколько баннеров от одной и той же баннерной сети, информация о том, что клиен тпосмторел картинку необходима впоследствии, например, для того, чтобы посчитать, сколько продаж какой-нить хуйни принесла реклама.
Я мб туплю, но вроде ничего из того, что здесь предложили в данной ситуации не подходит
Я мб туплю, но вроде ничего из того, что здесь предложили в данной ситуации не подходит
1) Первый запрос читает cookie в состоянии Xну можно на чтоб сервер возвращая инфу по 2-му запросу добавлял туда и то, что надо от первого
2) Воторой запрос читает cookie в состоянии X
3) Первый запрос присылает ответ и обновляет cookie до состояния Y = updated X
4) Второй запрос присылает ответ и обновляет cookie до состояния Z = updated X(а должно быть updated Y)
На странице может быть несколько баннеров от одной и той же баннерной сети, информация о том, что клиен тпосмторел картинку необходима впоследствии, например, для того, чтобы посчитать, сколько продаж какой-нить хуйни принесла реклама.Хранить в куках только uid пользователя. Все остальное хранить на сервере. Все так делают, разве нет?
Я мб туплю, но вроде ничего из того, что здесь предложили в данной ситуации не подходитИ правильно, что не подходит...
Кроме как править алгоритм банерообменной сетки ничего тебе посоветовать не могу....
Типа надо исправлять на серваке... или перестать пытаться наколоть банерообменную сетку, запихивая по 100 банеров на одну страницу, когда должон быть только один
на каком из 300 серверов мне хранить все что нужно о пользователе по его uid?
Почему много баннеров на одной странице это наебывание баннерной сети?
Я могу поправить алгоритм если есть идеи КАК это сделать. В принципе наверняка же должен быть способ сказать браузеры - дождись ответа на этот запрос, а потом уже типа пошли другой
Я могу поправить алгоритм если есть идеи КАК это сделать. В принципе наверняка же должен быть способ сказать браузеры - дождись ответа на этот запрос, а потом уже типа пошли другой
Сервера разные в общем случае. я же говрил уже раньше
В принципе наверняка же должен быть способ сказать браузеры - дождись ответа на этот запрос, а потом уже типа пошли другойНасколько я понимаю, ровно один - грамотным использованием JavaScript.
ну в таком случае можно поставить на странице условие, что если подгрузился первый банер, то грузить следующий...
т.е. обработка событий onLoad...
Как вариант - если инклюдить банеры - то последней строкой слать код инклюда следующего банера с уже измененными куки в виде начального условия.
А на серваке сделать проверку, если в запросе явно прописаны переменные - работать с ними, а если нет - то из кукисов...
Хотя, конечно, идиот тот, кто придумал 300 серверов для сети использовать... надо такое дело централизовать и там всю инфу хранить, а так - потеря данных - плевое дело...
т.е. обработка событий onLoad...
Как вариант - если инклюдить банеры - то последней строкой слать код инклюда следующего банера с уже измененными куки в виде начального условия.
А на серваке сделать проверку, если в запросе явно прописаны переменные - работать с ними, а если нет - то из кукисов...
Хотя, конечно, идиот тот, кто придумал 300 серверов для сети использовать... надо такое дело централизовать и там всю инфу хранить, а так - потеря данных - плевое дело...
надо такое дело централизовать и там всю инфу хранить, а так - потеря данных - плевое дело...Централизация нехило бабла обычно требует
Ты зря так демаешь(насчет идиотима)
Чем ты собираешься обрабатывать миллиард заросов в день?
Чем ты собираешься обрабатывать миллиард заросов в день?
А что тебе нужно хранить для пользователя? Количество показов? Храни на каждом сервере информацию по обращениям конкретно к этому серверу, а потом на отдельной машине собирай статистику со всех них.
Вообще удивительно, конечно, как люди пытаются поднять систему такого масштаба, не имея ни малейшего представления о том, как это следует делать. Некомпетентность жжот.
Скажика мне хотя бы один адрес, по которому крутятся твои баннеры. Я чую запах легкой наживы! =)
Вообще удивительно, конечно, как люди пытаются поднять систему такого масштаба, не имея ни малейшего представления о том, как это следует делать. Некомпетентность жжот.
Скажика мне хотя бы один адрес, по которому крутятся твои баннеры. Я чую запах легкой наживы! =)
пост Fj доступно объяснил мое мнение по поводу идиотизма...
А касательно цены централизации и кол-ва запросов - при таких маштабах должны быть и бабки, а если их нет - то и идея галимая...
А касательно цены централизации и кол-ва запросов - при таких маштабах должны быть и бабки, а если их нет - то и идея галимая...
А касательно цены централизации и кол-ва запросов - при таких маштабах должны быть и бабки, а если их нет - то и идея галимая...Почитай, как примерно гугл (сам поисковик) сделан - может изменишь мнение насчёт централизации.
А уж бабок у Google хватает: больше, наверное, только у Microsoft и, может быть, у Oracle.
Всем спасибо, все охуенно помогли
2FJ:
пример www.myspace.com
мб тебе это поможет.
То что ты предложил нихуя не работает. Информация нужна сразу а не через несоклько часов. Так что не надо тут поднимать вопрос о моей компетентности.
Был задан конкретный ворос - как это сделать средствами js/html.
пример www.myspace.com
мб тебе это поможет.
То что ты предложил нихуя не работает. Информация нужна сразу а не через несоклько часов. Так что не надо тут поднимать вопрос о моей компетентности.
Был задан конкретный ворос - как это сделать средствами js/html.
Пост FJ нихуя не подтвердил. Скажи мне, что все сервера гугла стоят в одном месте, давай
И вообще, господа, хватит плз тупить. Из того, что я сказал ранее, по-моему любой ребенок может понять что вариант, предложенный неким FJ'ем не подходит ну никак.
Еще ни один человек не предложил другого подходящего хранилища данных, кроме кук(и я не думаю, что такое существует).Причины изложены выше.
Еще ни один человек не предложил другого подходящего хранилища данных, кроме кук(и я не думаю, что такое существует).Причины изложены выше.
Скажи мне, что все сервера гугла стоят в одном месте"Централизация" это не значит что они стоят в одном месте... Если ты так этот термин понимаешь, то мне нечего добавить.
Меняй куки на строне клиента, а не на стороне сервера, тогда вероятность таких наездов друг на друга будет очень и очень незначительной.
при желании, можно также поверх куков поднять надежную журналируюмую "файловую" систему.
при желании, можно также поверх куков поднять надежную журналируюмую "файловую" систему.
миллиард заросов в деньМиллиард хитов в день не бывает, потому что это означает, что к вам зашел каждый человек имеющий интернет, и не раз. А вы не гугль все таки. Ну или кто-то типа fj вашу банерокрутилку на&*ывает
Нет я действительно не понимаю, в чем трудность поднять базу и хранить в ней сколько какому пользователю чего там показали, и обеспечить доступ к этой базе с каждой морды? Много данных не влезает в базу. Ну поднимите 10 баз. По uid-у база определяется каким-нибудь простеньким хешем. Короче проблема из пальца высосана, по-моему, ну правда это все уже и без меня поняли...
централизованность - это палка о двух концах...
Лучше по максимуму стараться обойтись без жесткой централизации.
Лучше по максимуму стараться обойтись без жесткой централизации.
Которая из них твоя?
Энивей, если в них всех хранится только юзерID, почему не запоминать его на сервере? И зачем он вообще нужен, если он изменяется после каждого захода?
ЗЫ: у меня была Мечта - чтобы ты хиты хранил в куках. Вот тогда бы я разгулялсо =)
Ты когда в инете серфишь только один баннер в день видишь?
Поясняю. Представь себе следующую ситуацию: приходит человек на сервер A и получает баннер. Он кликает на баннер и покупает то, что там предлагается купить(например). Сообщение о покупке приодит на сервер B. Как ты попытаешься обеспечить чтобы сервер B имел доступ к тому, что записал сервер A через минуту? При миллиарде хитов в день.
В данном случае централизованность никак помочь не может.
Разумеется другие данные статистики собираются в одном месте.
Поясняю. Представь себе следующую ситуацию: приходит человек на сервер A и получает баннер. Он кликает на баннер и покупает то, что там предлагается купить(например). Сообщение о покупке приодит на сервер B. Как ты попытаешься обеспечить чтобы сервер B имел доступ к тому, что записал сервер A через минуту? При миллиарде хитов в день.
В данном случае централизованность никак помочь не может.
Разумеется другие данные статистики собираются в одном месте.
Считай что тебе не повезло. У myspace.com стоит тэг генератор(теги примерно из 10 сетей).
Что значит "меняй куки на стороне клиента а не сервера"? Не понял=(
Насчет файловой системы - это тоже самое, что из пушки по мухам стрелять имхо.
Насчет файловой системы - это тоже самое, что из пушки по мухам стрелять имхо.
Ниче, ты все еще можешь разгуляться.
Хинт: ходи по инету и ищи баннеры с yieldmanager.com
После этого в цикле: 1) трешь куки 2) f5 3) клик
Хинт: ходи по инету и ищи баннеры с yieldmanager.com
После этого в цикле: 1) трешь куки 2) f5 3) клик
Повторяю для высшего офицерского состава. Децентрализация (масштабируемость если угодно) достигается тем, что существует разделение юзеров по базам. Централизация состоит в том, что все веб-морды имеют доступ ко всем базам. Современные сетевые технологии вполне это позволяют даже при миллиарде хитов в день. Я не знаю, что ты называешь "сервером", для меня "сервер" это все что не клиент. Хранить данные на сервере = хранить их не на клиенте. Как можно хранить хиты в куках? А если я тебе пришлю куку, в которой будет сказано, что я видел [подставить нужное] банеров?
Если каждый сервер в твоем случае должен узнавать о каждом запросе в течении минуты, то все сервера(расположенные географически в разных частях света) должны только и делать, что обмениваться этой информацией(это равносильно тому, что каждый из серверов обслуживает 1 миллирад запросов в день, бредовая затея).
Я НЕ храню статистику в куках - я там храню информацию о том была ли показана кокретная картинка кокретному человеку. Смирись с тем, что больше эту информацию хранить негде.
Тут все прямо такие компетентные, я фигею дорогая редакция
Я НЕ храню статистику в куках - я там храню информацию о том была ли показана кокретная картинка кокретному человеку. Смирись с тем, что больше эту информацию хранить негде.
Тут все прямо такие компетентные, я фигею дорогая редакция
Имхо единственный адекватный человек, отписавший в эту тему - .
У остальных только самомнение, какие-то знания и нелепые попытки применить эти знания там, где всего-то нужно посчитать и подумать
У остальных только самомнение, какие-то знания и нелепые попытки применить эти знания там, где всего-то нужно посчитать и подумать
+yorick
Предположим мы храним эту инфу в 10 разных базах.
Это значит, что количество запросов увеличится примерно в 1.5-2 раза(+редирект на нужный сервер). Кроме того это значит, что на каждую базу приходится 100 миллионов селектов и инсертов в день. Или 1157 в секунду(90% из них по сети). Смешно, да? Ежедневный прирост базы в этом случае составит 100 миллионов * 30 байт(uid, creative_id, date). 3 гига.
Если хранить свою базу на кадом отдельном сервере, то это будет значить: 1) увеличение времени отклика(причем нефиговое, если так случится что сразу много человек с одного сервера увидят баннер) 2) 100 метров - ежедневный прирост базы. 3) серверу пизда - баннеров нет 4) 40 инсертов и селектов ежесекундно.
Кто-нибудь все еще думает что это будет нормально работать? Куки и были сделаны для того, чтобы хранить такого рода информацию.
Никто не собирается хранить количество показов(и остальные подобные вещи, связанные с деньгами) в куках. Всем понятно что это бред. Но в данном случае, нам достаточно собирать статистику в RAM и раз в час скажем переносить ее в базу. А в базе аггрегировать. И никаких проблем с этим нет.
Это значит, что количество запросов увеличится примерно в 1.5-2 раза(+редирект на нужный сервер). Кроме того это значит, что на каждую базу приходится 100 миллионов селектов и инсертов в день. Или 1157 в секунду(90% из них по сети). Смешно, да? Ежедневный прирост базы в этом случае составит 100 миллионов * 30 байт(uid, creative_id, date). 3 гига.
Если хранить свою базу на кадом отдельном сервере, то это будет значить: 1) увеличение времени отклика(причем нефиговое, если так случится что сразу много человек с одного сервера увидят баннер) 2) 100 метров - ежедневный прирост базы. 3) серверу пизда - баннеров нет 4) 40 инсертов и селектов ежесекундно.
Кто-нибудь все еще думает что это будет нормально работать? Куки и были сделаны для того, чтобы хранить такого рода информацию.
Никто не собирается хранить количество показов(и остальные подобные вещи, связанные с деньгами) в куках. Всем понятно что это бред. Но в данном случае, нам достаточно собирать статистику в RAM и раз в час скажем переносить ее в базу. А в базе аггрегировать. И никаких проблем с этим нет.
Учитывая что "миллиард хитов в день" ты взял с потолка, все эти расчеты приобретают особую осмысленность.
Почему с потолка? Это реальное число. Отступление по всем флангам нах?
> Что значит "меняй куки на стороне клиента а не сервера"? Не понял=(
Куки можно читать и ставить, как на сервере, так и на клиенте через JS.
Если ты их меняешь на сервере - то у тебя появляется довольно большая задержка между чтением и записью куки, что и приводит к высокой вероятности того, что в эту задержку успеет вклиниться другой запрос, меняющий эту же куку.
Если же ты будешь менять куку через JS, то время между чтением и изменением - будет небольшим, что позволит резко уменьшить конфликты.
> Насчет файловой системы - это тоже самое, что из пушки по мухам стрелять имхо.
Это только страшно звучит, на самом деле все просто.
Нам нужно при записи убедиться, что мы ничего лишнего не затерли, для этого можно, например, использовать подход ethernet.
для этого заводим две куки - одна будет блокировкой, другая - данные.
блокировка: 0 - не заблокирована, != 0 заблокирована.
если блокировка - незаблокирована, генерим случайное число, и пишем в блокировку.
выжидаем некоторое время, например, 100 мс, читаем блокировку - если там наше число, значит это мы заблокировали куку, если число другое - значит заблокировал кто-то другой (в этом случае - ждем когда данные разблокируются).
далее меняем данные, снимаем блокировку(пишем 0).
Дальше надо предусмотреть таймауты, после которых считать, что, например, процесс который установил блокировку - накрылся, и значит надо такую блокировку убирать.
Используя вот такой алгоритм - мы построили надежную, в условиях совместной записи, "файловую" систему поверх куков.
ps
правильнее, конечно, было написать: надежную систему хранения данных, а не "файловую" систему.
Куки можно читать и ставить, как на сервере, так и на клиенте через JS.
Если ты их меняешь на сервере - то у тебя появляется довольно большая задержка между чтением и записью куки, что и приводит к высокой вероятности того, что в эту задержку успеет вклиниться другой запрос, меняющий эту же куку.
Если же ты будешь менять куку через JS, то время между чтением и изменением - будет небольшим, что позволит резко уменьшить конфликты.
> Насчет файловой системы - это тоже самое, что из пушки по мухам стрелять имхо.
Это только страшно звучит, на самом деле все просто.
Нам нужно при записи убедиться, что мы ничего лишнего не затерли, для этого можно, например, использовать подход ethernet.
для этого заводим две куки - одна будет блокировкой, другая - данные.
блокировка: 0 - не заблокирована, != 0 заблокирована.
если блокировка - незаблокирована, генерим случайное число, и пишем в блокировку.
выжидаем некоторое время, например, 100 мс, читаем блокировку - если там наше число, значит это мы заблокировали куку, если число другое - значит заблокировал кто-то другой (в этом случае - ждем когда данные разблокируются).
далее меняем данные, снимаем блокировку(пишем 0).
Дальше надо предусмотреть таймауты, после которых считать, что, например, процесс который установил блокировку - накрылся, и значит надо такую блокировку убирать.
Используя вот такой алгоритм - мы построили надежную, в условиях совместной записи, "файловую" систему поверх куков.
ps
правильнее, конечно, было написать: надежную систему хранения данных, а не "файловую" систему.
Первый вариант не подходит, так как кука зависит от выбранного баннера(процесс выбора нетривиален, происходит на сервере).
А за второй - спасибо.
А за второй - спасибо.
Это реальное числоРеальное, значит замени число 10 на такое, которое подходит.
10 не подходит, максимум 300, который тоже не подходит(читай пост). Никакое число не подходит. И не подойдет - с увеличением числа баз проблем станет только больше. Зачем связываться стаким геморроем когда есть куки?
Ладно наконец то я понял что в куках хранится информация о том какой банер лучше показать а не о том сколько чего показано. Можно в куках. 
Имхо единственный адекватный человек, отписавший в эту тему - .Ты бы на себя посмотрел.... первые постов 20 из тебя вытягивали инфу, что это для банеров надо...
У остальных только самомнение, какие-то знания и нелепые попытки применить эти знания там, где всего-то нужно посчитать и подумать
Ты когда научишься правильно задачу ставить - тогда и приходи...
А то как же, взялся за проект, в котором сам не рубишь и еще и людей, которые тебе пытаются помочь основываясь на той скудной инфе, что ты предоставил обсираешь...
Если хочешь по нормальному - пиши кодом, что есть, что делаешь, какая ошибка возникает, и какие есть ограничения на исправления этой ошибки...
Умник нах..... руки бы поотрывал...
Ты заголовок читал? Там написано: html/js. Единственные 2 человека которые стали писать по теме - yorick и . А остальные стали учить меня писать сервер(который и так работает, да еще что-то там про некомпетентность и тд и тп).
Так что иди себе руки оторви
Так что иди себе руки оторви
ну тут ты вообще неправ...
если внимательно почитаешь мой второй пост в твоей теме, то там как раз вариант на жабаскрипте описан... А то, что ты его не понял, или не принял - это все из-за того, что ты изначально неправильно задачу описал.
Как правильно - тебе уже сказали. Давай код, мы его отдебажим и перепишем, что бы все было ОК...
А так в теме можно что угодно писать, а потом говорить , что все дураки...
Тебе люди помочь хотят, и пишут ответы в меру того, как понимают вопрос.
А раз никто тебе нормально не ответил - значит проблема в постановке вопроса...
если внимательно почитаешь мой второй пост в твоей теме, то там как раз вариант на жабаскрипте описан... А то, что ты его не понял, или не принял - это все из-за того, что ты изначально неправильно задачу описал.
Как правильно - тебе уже сказали. Давай код, мы его отдебажим и перепишем, что бы все было ОК...
А так в теме можно что угодно писать, а потом говорить , что все дураки...
Тебе люди помочь хотят, и пишут ответы в меру того, как понимают вопрос.
А раз никто тебе нормально не ответил - значит проблема в постановке вопроса...
onload рассматривается как вариант
но его я знал до того как запостил вопрос сюда. он даже подходит более-менее
Мне ответили - darkGray
но его я знал до того как запостил вопрос сюда. он даже подходит более-менее
Мне ответили - darkGray
ну так какие проблемы? переформулируй задачу, учитывая те знания, которые приобрел читая этот тред и будет тебе счастье..
проблем никаких. тред можно закрывать
В принципе наверняка же должен быть способ сказать браузеры - дождись ответа на этот запрос, а потом уже типа пошли другойОтвет на запрос это релоад страницы. Если ты готов после каждого клика на баннер делать релоад страницы, то задача решается элементарно.
Не легче ли тогда использовать сессии?
Непонятно, почему они не подходят автору...
Непонятно, почему они не подходят автору...
Чем плохи сорок инсертов/селектов в секунду?
Кстати, даже под винду хр есть такая замечательная вещь, которая из части оперативки делает раздел... и можно запланировать, как часто делать бэкап этого раздела на винчестер... вот тебе такая идея, раз сам не можешь придумать, что с базой делать
Кстати, даже под винду хр есть такая замечательная вещь, которая из части оперативки делает раздел... и можно запланировать, как часто делать бэкап этого раздела на винчестер... вот тебе такая идея, раз сам не можешь придумать, что с базой делать
1) в варианте когда у каждого сервера своя база и свой набор клиентов и так дохуя недостатков. Они описаны на предыдущей странице. Приростбазы в этом варианте 100 метров в день - итого 3 гига за месяц, нужно объяснять чем плохи 40 селектов в секунду в 3хгиговой базе(а если рассматривать long-term, то еще больше)? инесрты хуй с ними, ты прав, можно раз в час скажем.
> Чем плохи сорок инсертов/селектов в секунду?
это средняя нагрузка.
Пиковая нагрузка - точно может в 10-100-1000 раз быть больше.
Реляционные базы - очень не любят (тормозят на этом) всякие изменения данных.
это средняя нагрузка.
Пиковая нагрузка - точно может в 10-100-1000 раз быть больше.
Реляционные базы - очень не любят (тормозят на этом) всякие изменения данных.
инесрты хуй с нимиУ тебя нет уникальных полей?
нужно объяснять чем плохи 40 селектов в секунду в 3хгиговой базеЕсли я не ошибаюсь - во всех современных БД можно индексировать поля... и тогда 40 селектов в 3гиговой базе займут не сильно больше времени, чем в 3метровой...
Хотя, инсерт тогда будет занимать порядка столько же времени, сколько и селект - но навряд ли при не совсем уж гигантском их количестве это действительно окажет какое-то сильное влияние...
Сессии не подходят, так как они перерастут на самом деле в uid(так как сессии длятся бесконечное время а это уже много обсуждалось
в этом варианте есть уникальное поле - uid. машина не справится с такой нагрузкой - dark gray прав. Помимо селектов надо и другие вещи тоже делать, алгоритм выбора там, все такое. Это же пиздец что будет. 25 мс на запрос в среднем(а распараллеливать селекты и обработку это лишниий гемор и усложнение логики ненужное). Где хранить базу в long term? что делать если на какой-нибудь машине слетел винт - все машины бекапить раз в час?
в этом варианте есть уникальное поле - uidТо есть, количество инсертов всё-таки важно...
Если ты селекты тоже по уид делаешь - чем плоха индексация? Очень сильно уменьшается как время селекта, так и время инсерта - до порядка логарифма размера базы (сейчас - порядка размеры базы)... а тогда - уже не очень заметно, 3 гига там или гораздо меньше...
> Если ты селекты тоже по уид делаешь - чем плоха индексация?
> Очень сильно уменьшается как время селекта, так и время инсерта - до порядка логарифма размера базы (сейчас - порядка размеры базы)
для изменения данных - есть обратная зависимость - чем больше индексов, тем намного тормознее работают insert-ы.
> Очень сильно уменьшается как время селекта, так и время инсерта - до порядка логарифма размера базы (сейчас - порядка размеры базы)
для изменения данных - есть обратная зависимость - чем больше индексов, тем намного тормознее работают insert-ы.
Чем больше индексируемых полей, или чем больше строк?
чем больше строк - тем тормознее - это и так понятно.
чем больше индексируемых полей - тем выше тормоза при вставке.
чем больше индексируемых полей - тем выше тормоза при вставке.
Поле вроде планируется только одно - уид?
по-моему разговор ни о чем
зачем все это нужно если есть куки? + в промышленном масштабе это не может работать стабильно
зачем все это нужно если есть куки? + в промышленном масштабе это не может работать стабильно
В любом случае, когда у клиента плохой коннект: у него может сразу грузится две твоих страницы, и обоим придут одни и те же куки... и сохранится в его куки - только одно из этих двух посещений...
Оставить комментарий
ark21
Ситуация - есть сервер, который обрабатывает n видов запросов(и при этом пишет что-то в cookie).Все бы ничего, но если какой-нибудь сайт вставляет 2 или более запроса на страницу, то происходит следющее:
1) Первый запрос читает cookie в состоянии X
2) Воторой запрос читает cookie в состоянии X
3) Первый запрос присылает ответ и обновляет cookie до состояния Y = updated X
4) Второй запрос присылает ответ и обновляет cookie до состояния Z = updated X(а должно быть updated Y)
В итоге один из запросов не сохраняется в cookie - нежелательный эффект
Какие есть простые способы застваить браузер делать сначала 3) а потом 2)? Желательно не особо запарно для владельца сайта, вставлябщего эти запросы