Собственно, мне нужно передавать переменные между запросами на своем сайте.
Есть такой пример
Я правильно понимаю, что эта кукасессия будет передаваться по всем страницам сайта при переходе с одной на другую?
Я могу написать
и получить на другой странице ‘{“cookies”: {“sessioncookie”: “123456789”}}’?

Спасибо!
Александр.

Я не большой спец. Но выглядит странно.
В вашем вопросе то что вы называете cookies вовсе не cookies. Это вызывает путаницу.

ajk-pro
Я правильно понимаю, что эта кукасессия будет передаваться по всем страницам сайта

Простой ответ НЕПРАВИЛЬНО.
Но вы не привели ни строчки серверного кода, поэтому непонятно что вы имеете ввиду.
Сейчас получается что вы с сервера пошлете сетевой запрос самому себе. Естественно вы получите то что вернет сервер. Что вы предусмотрите возвращать по этому адресу то и будет.
И это никак не переменные. Это статические данные.

Краеугольным камнем http является абсолютная независимость запросов к серверу. Логическую связь между запросами вы можете организовать на сервере только на основе анализа содержания запроса.

Те содержимое ответа будет определяться только состоянием сервера и текстом запроса.

Классическим методом хранения состояния сервера является использование базы данных. Один запрос меняет данные, другой их извлекает.

Если есть затык с производительностью то можно и просто в общей памяти данные держать, но вы четко тогда должны понимать как идет обработка запросов на сервере. Многопоточно, асинхронно, либо запуском новых процессов, возможно даже на разных компьютерах.

Судя по вашему вопросу, обсуждать эти варианты пока преждевременно. Передавайте данные через СУБД.

p.s.
Сейчас очень популярны SPA. Страница у вас одна, а вид меняется средствами js. Можно и между разными страницами данные передавать. Сделать это гораздо проще чем на сервере независимость запросов преодолевать.

doza_and
Но вы не привели ни строчки серверного кода, поэтому непонятно что вы имеете ввиду.

Приведенный выше код из распространенного примера и он на сервере.
Я имею некоторый опыт написания движка сайта, на на php. В php есть некие сессии и через них можно передавать некие данные между страницами сайта. Сессии там хранятся на сервере. Куки естественно у клиента.
Теперь я пытаюсь освоить Питон. Библиетека requests конечно мощная и кое что мне понятно. Но их сессии приводят в ступор.
Вопрос поставлю так: как мне передавать некоторые данные между страницами?
Ну, не через get/post же? Сессии в реквесте что-то другое? Что?

Спасибо!
Александр.

p.s. Ну, какой-то капли понимания не хватает…

ajk-pro
Приведенный выше код из распространенного примера и он на сервере.

Если мы будем друг другу писать в таком стиле, о неком “распространенном примере”, без конкретного указания источника, то общение закончится чем-то вразумительным лет через 100.

Организовать веб сервер на питоне можно сотней способов. И способ передачи данных в каждом будет свой.

Например если используете aiohttp то вот вам пример хранения данных в сессиях для совместного использования:

https://docs.aiohttp.org/en/stable/web_quickstart.html#user-sessions

А если flask то этак.
https://pythonru.com/uroki/13-sessii-vo-flask
Это пример показывает что php сессии и сессии flask отличаются даже местом хранения данных.

Если вам просто надо хранить глобальные данные в памяти сервера, не привязывая их к пользователю то в aiohttp проще их хранить в экземпляре приложения.

https://docs.aiohttp.org/en/stable/web_advanced.html#data-sharing-aka-no-singletons-please

p.s.
Если вы представляете себе в голове приложение как набор страниц, то я бы рекомендовал и хранить данные у клиента передавая и используя их средствами javascript.

ajk-pro
Я имею некоторый опыт написания движка сайта, на на php. В php есть некие сессии и через них можно передавать некие данные между страницами сайта. Сессии там хранятся на сервере. Куки естественно у клиента.

Видимо, ты не понимаешь, что такое сессии и зачем их придумали вообще. Сессия - это не что-то там в PHP, питоне, на сервере и так далее. Сессия - это абстракция такая, которая даёт упорядочить пары запрос-ответ в HTTP-протоколе и построить такой направленный непрерывный процесс, для которого изначально в HTTP-протоколе нет средств. И вот для этого сессии реализовали в PHP, питоне и других языках. Поэтому для изучения сессии нужно только взять HTTP-протокол и сессию без какого-либо языка и изучить её суть и её границы. После этого ты начнёшь понимать, что в одном языке сессии реализованы красиво, а в другом языке сессии реализованы как-то по-тупому.

Сессия просто соединяет запросы друг с другом через информацию в HTTP-заголовках. Таким образом клиент знает, что запрос такой-то следует за запросом таким-то и может сообщить серверу “теперь я посылаю следующий запрос по очереди”. А сервер знает, что ответ такой-то следует за ответом таким-то и может сообщить клиенту “теперь я посылаю следующий ответ по очереди”. Таким образом эта непрерывная цепочка запросов-ответов объединяется в сессию. Между ними могут происходить другие запросы-ответы, но они не будут замешиваться в эту сессию, потому что в них не будет признаков этой сессии. Так ты можешь участвовать в нескольких сессиях параллельно, запросы и ответы у них могут быть перемешаны во времени как угодно и следовать в каком угодно порядке, но как на клиенте, так и на сервере эти запросы и ответы будут разноситься по своим сессиям, которые строго упорядочены и в которых нет лишних запросов или лишних ответов, не относящихся к этим сессиям. Всё это придумано для того, чтобы создать упорядоченности, которых в HTTP-протоколе изначально нет.

Дальше уже возникают вопросы реализации сессии: а как её хранить на сервере, в чём; а как сделать так, чтобы никто чужой не влез не в свою сессию, как-то её зашифровать надо, засекретить; а что можно передавать внутри сессий, какие-то капсулы с данными, как их построить. Это всё идёт уже после понятия сессии и может быть выполнено и реализовано по-разному. И эта реализация зависит как от ума дизайнеров и их дальновидности и знаний в области безопасности, так и от возможностей языка, в котором это реализовывается, потому что языки тоже могут быть сделаны не очень подходяще для своего развития. Поэтому в PHP, например, ты и наблюдаешь часто какие-то неродные, обходные моменты, по которым видно, что их туда всунули так, чтобы лишь бы работало.


tags: http session