Начитался много примеров, видял что люди постят непонятные вещи на asp.net сайте, итак моя проблема:
Данные на вебформе адресуются с помощью урл, и так же как и всем остальные нет желания чтобы этот линк постоянно торчал в браузера, нужно его удалить.(проверка на постбак не удовлетворяет требованиям)

Алгоритм:
1. достаём из урл нужные параметры
2. сохраняем их в сессию, каждый в отдельный объект
3. делаем редирект на страницу без параметров

после редиректа бряки на страницу не попадают, происходит чтото доужаса странное! Сессия теряется, все значения становятся дефолтными

Response.Redirect("Home.aspx", false);

Но, как только я к редиректу добавлю "?" ("Home.aspx?") или ?whatever, то вызов происходит и сессия присутствует, но при последующем разе приходится это самое whatever поменять на чтонибуть типа whatever2, и я достигаю желаемого результата чередуя их туда сюда. Очень похоже на кэширование, чтото вроде

if (CurrentUrl == this.Url)
{
   ExitAndDoNotFirePageEvents(); // !!!!
}

Самое главное то, что это работало и потом резко перестало (возможно я ставил какие то фиксы например VS SP1), но код один и тот же!

Есть у каво нибудь комментарии по данному вопросу?

Здравствуйте, Calabon, Вы писали:

C>Есть у каво нибудь комментарии по данному вопросу?
C>

Посмотри сниффером, какие заголовки приходят браузеру с этой страницы (на тему кеширования). М.б., последующего запроса нет ВООБЩЕ ? (ну или бряк в page load поставь)

Здравствуйте, Calabon, Вы писали:

C>Самое главное то, что это работало и потом резко перестало (возможно я ставил какие то фиксы например VS SP1), но код один и тот же!
C>Есть у каво нибудь комментарии по данному вопросу?

А информация о сессии не в query string храниться? если да, то переставь на куки файл

Здравствуйте, vityanya, Вы писали:

V>Здравствуйте, Calabon, Вы писали:

C>>Самое главное то, что это работало и потом резко перестало (возможно я ставил какие то фиксы например VS SP1), но код один и тот же!
C>>Есть у каво нибудь комментарии по данному вопросу?

V>А информация о сессии не в query string храниться? если да, то переставь на куки файл

Если б у него было настроено хранение ключа сессии в query string, тогда б она была пустая и с ?whatever/?whetever2
imho тут что-то другое...

BTW: если ключ сессии не в query string, то как раз в куки хранится. А уже по этому ключу всю остальную инфу можно и на сервере хранить. Так что принципиальной разницы быть не должно

Здравствуйте, Calabon, Вы писали:

C>Начитался много примеров, видял что люди постят непонятные вещи на asp.net сайте, итак моя проблема:

У нас была похожая проблема. Нужно было очистить QueryString, но Response.Redirect нам не помогал, тк. при открытии ссылки из других приложений (например если это ссылка в письме в Аутлуке) редирект делался этим приложением (Аутлуком), а не IE. Соотвественно сессия ТЕРЯЛАСЬ.

Поэтому редирет сделали на Javascript:

private void JavascriptRedirect()
{
  Response.Clear();
  string script = "";
  script += "<script type=\"text/javascript\">\r\n document.location = \"default.aspx\";\r\n </script>\r\n";
  Response.Write(script);
  Response.End();
}

Здравствуйте, Calabon, Вы писали:
Ужос. Ужос-ужос.
Нельзя так писать. И задача, и решение, и проблема которую вы получили, и слова, которыми вы это описываете — всё это беспросветный ужос.

Зачем вам параметры сабмита в сессии? Вы вообще понимаете, что такое веб? Чем отличается Get от Post? Что такое Redirect? Что такое сессия, зачем она нужна, и как она работает? Как кэшируются запросы, и почему?

Поставьте fiddler2.com — это первый шаг в веб-разработке. Пока вы не начнете понимать, что там пишется в лог при навигации по вашему сайту, всё остальное лишено смысла.

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, Calabon, Вы писали:
S>Ужос. Ужос-ужос.
S>Нельзя так писать. И задача, и решение, и проблема которую вы получили, и слова, которыми вы это описываете — всё это беспросветный ужос.

Да знаю я это. вапще всйо ужос!

S>Зачем вам параметры сабмита в сессии? Вы вообще понимаете, что такое веб?

Что значит зачем? Это очень даже избитая тема в инете. Нужно запретить вторичное выполнение действий по обработке урл. Проста туча вапросов к разработчикам ASP.NET почему может терятся сессия ниставо ниссиво.

S>Чем отличается Get от Post? Что такое Redirect? Что такое сессия, зачем она нужна, и как она работает? Как кэшируются запросы, и почему?

Очень интересно ваше мнение о этом всём. Не знаю только одного — как кэшируются запросы.. и па каким таким вапросам ниставо ниссиво...
Вопсчем ты какой та бред написал.. тупа залашыл меня бес причины.. а лучшеп па делу.

S>Поставьте fiddler2.com — это первый шаг в веб-разработке. Пока вы не начнете понимать, что там пишется в лог при навигации по вашему сайту, всё остальное лишено смысла.

Использовал сниффер. То что сообщение Page_Load не вызывается я уверен. Редирект происходит — 302 Found.

Насколько я понял из обсуждения вы боретесь с пользовательской перегрузкой страницы и хотите избавится от сообщения "Перепослать данные ещё раз?"

Поддерживаю Антона целиком и полность.

Здравствуйте, Calabon, Вы писали:

C>Что значит зачем? Это очень даже избитая тема в инете. Нужно запретить вторичное выполнение действий по обработке урл. Проста туча вапросов к разработчикам ASP.NET почему может терятся сессия ниставо ниссиво.

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

здесь и здесь

цитата:

The Mantra
PRG pattern can be rephrased like this:

Never show pages in response to POST 
Always load pages using GET
Navigate from POST to GET using REDIRECT 

Repeat these lines before going to bed.

НО нигде там нет про то что нужно в сессию при этом данные писать, и/или чистить QueryString
наоборот. обычно наоборот — редирект делается со всей нужной информацией.

Здравствуйте, Calabon, Вы писали:

C>Что значит зачем? Это очень даже избитая тема в инете.
Она избита людьми, у которых отсутствует часть мозга, необходимая для разработки веб-приложений.
C>Нужно запретить вторичное выполнение действий по обработке урл.
Нужно просто проектировать нормально, и не будет никаких запретов.
Основы веб: запросы GET не должны иметь побочных эффектов.
Повторяйте это на ночь по шестьсот раз, до просветления.
Тогда при "обработке урл" вторичное выполнение ничем не будет грозить. А освоив хидеры Expiration; Last-modified; If-modified-since, if-none-match, вы получите офигенный прирост производительности в них.

После этого, в принципе, можно понять, что побочные эффекты можно делать только при помощи метода POST. Обратное также верно: POST стоит использовать только в том случае, если у запроса будут побочные эффекты. Тогда жизнь станет легкой и приятной. Останется только две проблемы:
1. Быстрое двукратное нажатие на кнопку Send, что приводит к удваиванию запроса
2. Back после Send и Forward c "Retry". Что тоже приведет к удваиванию запроса.

Вторая проблема лечится редиректом после поста — 302. Редирект вызывает смену глагола на GET, а POST исчезает из history браузера.
Первую проблему лечат разными способами. Можно поискать в гугле по словам Post Exactly Once; можно просто в OnSubmit формы дизаблить кнопку Send.

C>Проста туча вапросов к разработчикам ASP.NET почему может терятся сессия ниставо ниссиво.
Осваивайте фиддлер, и сессии пребудут с вами. Кстати, сессия — вообще зло, если что. Она не дает делать высокопроизводительные приложения. Сходите на google.com, подумайте, почему гугл не использует сессии.

S>>Чем отличается Get от Post? Что такое Redirect? Что такое сессия, зачем она нужна, и как она работает? Как кэшируются запросы, и почему?
C>Очень интересно ваше мнение о этом всём. Не знаю только одного — как кэшируются запросы.. и па каким таким вапросам ниставо ниссиво...
Ну вот кэширование респонсов обычно помогает понять, зачем делать всё правильным способом, а неправильным — не делать.
C>Вопсчем ты какой та бред написал.. тупа залашыл меня бес причины.. а лучшеп па делу.
С причиной.

C>Использовал сниффер. То что сообщение Page_Load не вызывается я уверен. Редирект происходит — 302 Found.

Здравствуйте, Sinclair, Вы писали:

S> Кстати, сессия — вообще зло, если что. Она не дает делать высокопроизводительные приложения. Сходите на google.com, подумайте, почему гугл не использует сессии.

Можно, кстати, какие-нибудь указатели на то, как жить без сессии? Потому как мы бы с удовольствием, но не умеем пока.

Здравствуйте, Maxim Golov, Вы писали:
MG>Можно, кстати, какие-нибудь указатели на то, как жить без сессии? Потому как мы бы с удовольствием, но не умеем пока.
Попробуйте что-то почитать о ViewState & Page Life Cyrcle

Здравствуйте, Sinclair, Вы писали:

S>Основы веб: запросы GET не должны иметь побочных эффектов.
S>Повторяйте это на ночь по шестьсот раз, до просветления.
S>Тогда при "обработке урл" вторичное выполнение ничем не будет грозить. А освоив хидеры Expiration; Last-modified; If-modified-since, if-none-match, вы получите офигенный прирост производительности в них.

Это очень хорошее замечание. При необходимости разработки высокопроизводительных приложений обязательно буду использовать информацию из HTTP Headers. Но в моём случае это просто одна страница, которая в очень короткие сроки должна заработать.(максимальное кол-во одновременных пользователей человек 5)

S>После этого, в принципе, можно понять, что побочные эффекты можно делать только при помощи метода POST. Обратное также верно: POST стоит использовать только в том случае, если у запроса будут побочные эффекты. Тогда жизнь станет легкой и приятной. Останется только две проблемы:
S>1. Быстрое двукратное нажатие на кнопку Send, что приводит к удваиванию запроса
S>2. Back после Send и Forward c "Retry". Что тоже приведет к удваиванию запроса.

Мне это известно, но опять же повторяю, что требуемый функционал разрешает мне сделать по — другому.
Это линк это просто что то вроде view state для страницы, только основной функционал сделал на AJAX и поэтому действия выполняются на странице после её загрузки.

S>Вторая проблема лечится редиректом после поста — 302. Редирект вызывает смену глагола на GET, а POST исчезает из history браузера.
S>Первую проблему лечат разными способами. Можно поискать в гугле по словам Post Exactly Once; можно просто в OnSubmit формы дизаблить кнопку Send.

Чего мне действительно не хватает это подобного 307 Temporary, но не preserve POST method, а чтоб частично preserve Query String и preserve Form Data (но это мечты не к изменению стандарта HTTP)

S>Осваивайте фиддлер, и сессии пребудут с вами. Кстати, сессия — вообще зло, если что. Она не дает делать высокопроизводительные приложения. Сходите на google.com, подумайте, почему гугл не использует сессии.

Как я говорил, сниффер использую. Да, согласен, сессия это зло — расширяемость приложения сводится к нулю, но в данном случае позволяю сибе
для быстроты эксперимента сохранить промежуточные данные в сессию. Всё это вообщем очень хорошо... всё достаточно понятно, что когда использовать... Почему же вдруг запросы начали кэшироваться..? Я добивался таких результатов путём вызова редиректа внутри кода на туже страницу при постбэке — Page_Load уже не вызывается, выполняется метод GET к странице и никого не интересует, что требуется preserve POST, код:

Response.Redirect("CurrentPage.aspx"); 
// или
Response.Redirect("CurrentPage.aspx", false); // с сайта разработчиков ASP.NET узнал что ThreadAbortExecution уничтожает cookie c seesionId
// т.е. Response.End() не вызывается, что некоторым помогало
// что аналогично 
Response.ResponseLocation = "CurrentPage.aspx";
Response.StatusCode = 307;

Любой вызов приводит к потере сессии в случае постбака, т.е. к кэшированию страницы... мой выход добавление рандомного числа к ссылке.
Всё понятно с проектированием, и что так лучше не делать, проста неочевидные проблемы, когда пытаешься сделать как проще.
Что думаешь по этому поводу?

Здравствуйте, Norex, Вы писали:

MG>>Можно, кстати, какие-нибудь указатели на то, как жить без сессии? Потому как мы бы с удовольствием, но не умеем пока.
N>Попробуйте что-то почитать о ViewState & Page Life Cyrcle

Можно подробнее — как VIEWSTATE и знание Page Lifecycle поможет обойтись без того, например, чтобы хранить редактируемый юзером бизнес-объект в Session (предположим, что мы уже смирились и решили, что для аутентикации будем использовать куки. Но бизнес-объект в куки не влезет).

Здравствуйте, Maxim Golov, Вы писали:

MG>Можно подробнее — как VIEWSTATE и знание Page Lifecycle поможет обойтись без того, например, чтобы хранить редактируемый юзером бизнес-объект в Session (предположим, что мы уже смирились и решили, что для аутентикации будем использовать куки. Но бизнес-объект в куки не влезет).
Начать, наверное, стоит с того, что viewstate — это зло. По тем же, в принципе, причинам — используя viewstate, вы отказыааетесь от адресуемости.
Впрочем, для сценария "редактирование бизнес-объекта" viewstate вполне подойдет, поскольку вряд ли кто-то захочет поставить букмарк "в середину" процесса редактирования.

Использовать для этого сессию — крайне плохое решение.
1. Что будет, если пользователь вышел покурить, а его сессия протухла? Теряем все сделанные изменения?
2. Что будет, когда вы удлините время жизни сессии, и одновременно в сессии будут лежать тысячи бизнес-объектов?
3. Что будет, когда один пользователь попытается поредактировать сразу два бизнес-объекта?

Viewstate масштабируется гораздо лучше.

Здравствуйте, Calabon, Вы писали:

C>Что думаешь по этому поводу?
Думаю, что моих телепатических талантов не хватает, чтобы понять, в чем именно проблема. Я своё мнение написал, а в какой строке у тебя ошибка, мне отсюда не видно.

Здравствуйте, Sinclair, Вы писали:

S>Здравствуйте, Calabon, Вы писали:

C>>Что значит зачем? Это очень даже избитая тема в инете.
S>Она избита людьми, у которых отсутствует часть мозга, необходимая для разработки веб-приложений.
C>>Нужно запретить вторичное выполнение действий по обработке урл.
S>Нужно просто проектировать нормально, и не будет никаких запретов.
S>Основы веб: запросы GET не должны иметь побочных эффектов.
S>Повторяйте это на ночь по шестьсот раз, до просветления.
S>Тогда при "обработке урл" вторичное выполнение ничем не будет грозить. А освоив хидеры Expiration; Last-modified; If-modified-since, if-none-match, вы получите офигенный прирост производительности в них.

S>После этого, в принципе, можно понять, что побочные эффекты можно делать только при помощи метода POST. Обратное также верно: POST стоит использовать только в том случае, если у запроса будут побочные эффекты. Тогда жизнь станет легкой и приятной. Останется только две проблемы:
S>1. Быстрое двукратное нажатие на кнопку Send, что приводит к удваиванию запроса
S>2. Back после Send и Forward c "Retry". Что тоже приведет к удваиванию запроса.

S>Вторая проблема лечится редиректом после поста — 302. Редирект вызывает смену глагола на GET, а POST исчезает из history браузера.
S>Первую проблему лечат разными способами. Можно поискать в гугле по словам Post Exactly Once; можно просто в OnSubmit формы дизаблить кнопку Send.


как то ты сложно завернул. имхо паттерн PRG (POST REDIRECT GET или GET Afer POST ) попроще будет для понимания.

Здравствуйте, Sinclair, Вы писали:

S>Начать, наверное, стоит с того, что viewstate — это зло. По тем же, в принципе, причинам — используя viewstate, вы отказыааетесь от адресуемости.
S>Впрочем, для сценария "редактирование бизнес-объекта" viewstate вполне подойдет, поскольку вряд ли кто-то захочет поставить букмарк "в середину" процесса редактирования.

S>Использовать для этого сессию — крайне плохое решение.
S>1. Что будет, если пользователь вышел покурить, а его сессия протухла? Теряем все сделанные изменения?
S>2. Что будет, когда вы удлините время жизни сессии, и одновременно в сессии будут лежать тысячи бизнес-объектов?
S>3. Что будет, когда один пользователь попытается поредактировать сразу два бизнес-объекта?

S>Viewstate масштабируется гораздо лучше.

Я не очень осознал набор утверждений "viewstate — это зло" и "Viewstate масштабируется гораздо лучше". Это не подколка, это вопрос — как их интерпертировать вместе?

В конкретно нашем случае:
Случай 1 — не проблема, а фича, наше приложение автоматом завершает сессию после периода неактивности (требования безопасности)
Случай 2 — удаляем бизнес-объект после того, как он отредактирован, это не спасет?
Случай 3 — согласен, здесь хоть что-то надо класть на страницу тем или иным способом (ключ объекта?)

Сценарий записи объекта в viewstate:
— объект сериализуется и пересылается (по медленному интернету) пользователю
— при загрузке страницы объект пересылается обратно на сервер (по медленному интернету) и десериализуется

Сценарий записи объекта в сессию:
— сессия сохраняется на сервере сессии (в базе, в выделенном сервере сессии, так далее, эта часть системы нам подконтрольна), по быстрой внутренней сети. Скорее всего объект при этом тоже сериализуется
— при загрузке страницы сессия зачитывается с сервера, опять же по быстрой внутренней сети, десериализация опять же происходит

Есть подозрение, что при большом размере объектов хранить их в сессии выгоднее, чем во viewstate. Или я что-то упускаю?

Здравствуйте, Maxim Golov, Вы писали:




MG>Сценарий записи объекта в viewstate:
MG> — объект сериализуется и пересылается (по медленному интернету) пользователю
Так вы делаете интернет клиента еще более медленным
MG> — при загрузке страницы объект пересылается обратно на сервер (по медленному интернету) и десериализуется
И так тоже замедляете интернет то уже на пути к себе
Если есть БД то почему бы во вьюстейте не хранить уникальный ключ объекта в БД и потом при постбэке его поднимать
по ключу?
Зачем его запихивать во вьюстейт и если у вас нет
MG>Сценарий записи объекта в сессию:
MG> — сессия сохраняется на сервере сессии (в базе, в выделенном сервере сессии, так далее, эта часть системы нам подконтрольна), по быстрой внутренней сети. Скорее всего объект при этом тоже сериализуется
MG> — при загрузке страницы сессия зачитывается с сервера, опять же по быстрой внутренней сети, десериализация опять же происходит
с сервера ? если у вас сессия OutProc или в БД то по сути во втором случае в в своей БД храните 2 копии одних и тех же данных только в
разных форматах

MG>Есть подозрение, что при большом размере объектов хранить их в сессии выгоднее, чем во viewstate. Или я что-то упускаю?
Да есть глубочайшее подозрение что при хранении объектов в сессии а ЛУЧШЕ в БД горраздо эффективнее чем во вьюстейте.
Хотя как в том анекдоте whom how

Здравствуйте, Maxim Golov, Вы писали:

MG>Я не очень осознал набор утверждений "viewstate — это зло" и "Viewstate масштабируется гораздо лучше". Это не подколка, это вопрос — как их интерпертировать вместе?
Сессия — самое большое зло.
Viewstate — зло поменьше.
Stateless page — это самый правильный способ работы. Не всегда этот идеал достижим.

MG>В конкретно нашем случае:
MG>Случай 1 — не проблема, а фича, наше приложение автоматом завершает сессию после периода неактивности (требования безопасности)
Ок, требования безопасности могут иногда привести к уменьшению удобства. Хотя применение viewstate позволяет, в принципе, сохранить изменения пользователя, даже выполнив требования безопасности — ему просто придется выполнить повторный логин.
MG>Случай 2 — удаляем бизнес-объект после того, как он отредактирован, это не спасет?
Я же говорю — одновременно. Проблема именно в этом: вот вы отдали страницу для редактирования бизнес объекта, написали на ней ключ к сессии, объект положили в сессию.
Всё, совершенно неизвестно, придет ли когда-то submit, или уже никогда. Объект лежит в сессии, пожирает ценные ресурсы. Пришел другой человек, открыл другой объект.

MG>Случай 3 — согласен, здесь хоть что-то надо класть на страницу тем или иным способом (ключ объекта?)
Проблема не в странице, а в том, что нужно оба объекта хранить в сессии. Наивный подход типа Session["currentObject"] = ... не сработает.
Далее, если человек неудачно навигируется, открывая на редактирование всё новые и новые объекты, его сессия будет "распухать". В HTTP нет способа надежно отловить закрытие страницы. Сессия — не кэш, удаление "старых" объектов не предусмотрено. Соответственно, нагрузка на сервер будет необоснованно расти.

MG>Есть подозрение, что при большом размере объектов хранить их в сессии выгоднее, чем во viewstate. Или я что-то упускаю?
Во-первых, Я не очень понимаю, каким именно образом вам удастся "поредактировать" большой объект на одной странице.
Можно как-то пояснить мне, какой набор элементов управления отдастся пользователю, чтобы объем изменяемых данных превысил 50 килобайт?
Или речь про редактирование изображений?

Во-вторых, в свете вышесказанного, большие объекты положат ваш сервер еще быстрее, чем мелкие.