By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
424,649 Members | 1,816 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 424,649 IT Pros & Developers. It's quick & easy.

ASP.Net hell -> HttpContext.Items

P: n/a
After completely giving up on finding some way in my ASP.Net app to take a
query string URL and redirect to it as a POST instead, I went with a system
like so:
Upon "redirection," all the QueryString pairs are placed in
HttpContext.Current.Items and retrieved with a wrapper for Request.Params
that includes checks there. This works in general instances, but one
problem has come up that has me stuck: since the stuff is in the context and
not physically presented on a page anywhere, if I move to another page and
then hit "Back," my context items are once again lost, and the page won't
display properly. Seems like the only way to persist those fields correctly
is to either put them in the query string when I go from one page to
another, which I *can't reliably do because my URLs will exceed the limit
and result in an HTTP error*, or somehow POST the variables, which I also
have not been able to do because the Request.Forms collection is read-only,
and I cannot programmatically add hidden fields to the ASP.Net form (says I
can't modify the set of controls).

So given the aforementioned scenario, is ASP.Net simply incapable of
handling this? I would think not, since Java has allowed programmatic
POSTing + it seems just too restrictive to imagine that the designers would
have made it impossible to change pages when the # of KV pairs would
potentially exceed a URL's maximum allowable length. However, I have yet to
find an actual answer to the GET-to-POST questions that have been posed (the
answers veer more towards, "just do whatever you're trying to do another
way"), and this is searching over several years of usenet posts.
Nov 19 '05 #1
Share this Question
Share on Google+
7 Replies


P: n/a
It looks like you try to workaround something.

My first reaction would be to try to solve the orioginal problem rather than
trying to workaround it (ie what exactly prevents to POST if this is what
you want ?).

If you really need to post you could use WebClient to post to another page ;
there is nothing that should prevent to add hidden fields to a form and so
on....

I tried to retrieve the big picture but the other post from yyou I found
doesn't seem related (was a problem with frames ?).

Patrice

--

"Keith Patrick" <ri*******************@nospam.hotmail.com> a écrit dans le
message de news:OE**************@TK2MSFTNGP14.phx.gbl...
After completely giving up on finding some way in my ASP.Net app to take a
query string URL and redirect to it as a POST instead, I went with a system like so:
Upon "redirection," all the QueryString pairs are placed in
HttpContext.Current.Items and retrieved with a wrapper for Request.Params
that includes checks there. This works in general instances, but one
problem has come up that has me stuck: since the stuff is in the context and not physically presented on a page anywhere, if I move to another page and
then hit "Back," my context items are once again lost, and the page won't
display properly. Seems like the only way to persist those fields correctly is to either put them in the query string when I go from one page to
another, which I *can't reliably do because my URLs will exceed the limit
and result in an HTTP error*, or somehow POST the variables, which I also
have not been able to do because the Request.Forms collection is read-only, and I cannot programmatically add hidden fields to the ASP.Net form (says I can't modify the set of controls).

So given the aforementioned scenario, is ASP.Net simply incapable of
handling this? I would think not, since Java has allowed programmatic
POSTing + it seems just too restrictive to imagine that the designers would have made it impossible to change pages when the # of KV pairs would
potentially exceed a URL's maximum allowable length. However, I have yet to find an actual answer to the GET-to-POST questions that have been posed (the answers veer more towards, "just do whatever you're trying to do another
way"), and this is searching over several years of usenet posts.

Nov 19 '05 #2

P: n/a
WebClient isn't working for me because I lose my user's state information
(this is an authenticated ASP.Net app). I tried using WebClient, but it
would only take me back to the login page.
My problem is this: I need to go from page to page, but I transfer a lot of
information along the way (titles of a list of one to very many items, for
example, or the item chosen). The current system uses the query string for
this, but those lists of items can exceed 4k on occasion. However, I can
find no way anywhere within HttpContext.Current except for the Items
collection that can take that much information. I couldn't post the
information, as Page doesn't let me add controls to it programmatically, so
I couldn't add hidden fields on submit. Request's Param collections are
read-only of course, but Response lacks Java's .SetAttribute() (IIRC) for
putting KV pairs in the POST header. Items works for the most part except
that going Back loses context and therefore all of the values stored in the
Items collection. I'm against putting all data in all pages into ViewState
just to help this, and ultimately what I'm trying to basically do is
programmatically move to another page with POSTed data so I can avoid the
URL length limit. I'm looking at gutting out our app's navigation system
(user controls that do a Response.Redirect that I just changed to
Server.Transfer, with *it's* own problems) and making better use of
LinkButtons and (hopefully) implicit form submittal, but I still need a
clean way of putting those values in hidden fields on the page without
manually adding them to every page in the app.

"Patrice" <no****@nowhere.com> wrote in message
news:OO**************@tk2msftngp13.phx.gbl...
It looks like you try to workaround something.

My first reaction would be to try to solve the orioginal problem rather
than
trying to workaround it (ie what exactly prevents to POST if this is what
you want ?).

If you really need to post you could use WebClient to post to another page
;
there is nothing that should prevent to add hidden fields to a form and so
on....

I tried to retrieve the big picture but the other post from yyou I found
doesn't seem related (was a problem with frames ?).

Patrice

--

"Keith Patrick" <ri*******************@nospam.hotmail.com> a écrit dans le
message de news:OE**************@TK2MSFTNGP14.phx.gbl...
After completely giving up on finding some way in my ASP.Net app to take
a
query string URL and redirect to it as a POST instead, I went with a

system
like so:
Upon "redirection," all the QueryString pairs are placed in
HttpContext.Current.Items and retrieved with a wrapper for Request.Params
that includes checks there. This works in general instances, but one
problem has come up that has me stuck: since the stuff is in the context

and
not physically presented on a page anywhere, if I move to another page
and
then hit "Back," my context items are once again lost, and the page won't
display properly. Seems like the only way to persist those fields

correctly
is to either put them in the query string when I go from one page to
another, which I *can't reliably do because my URLs will exceed the limit
and result in an HTTP error*, or somehow POST the variables, which I also
have not been able to do because the Request.Forms collection is

read-only,
and I cannot programmatically add hidden fields to the ASP.Net form (says

I
can't modify the set of controls).

So given the aforementioned scenario, is ASP.Net simply incapable of
handling this? I would think not, since Java has allowed programmatic
POSTing + it seems just too restrictive to imagine that the designers

would
have made it impossible to change pages when the # of KV pairs would
potentially exceed a URL's maximum allowable length. However, I have yet

to
find an actual answer to the GET-to-POST questions that have been posed

(the
answers veer more towards, "just do whatever you're trying to do another
way"), and this is searching over several years of usenet posts.


Nov 19 '05 #3

P: n/a

Hi Keith:

I'd avoid Context.Items if you are moving from page to page - the
Items collection is only good for the duration of a single web
request.

You've ruled out view state. Other options include the Session
collection (server side) or a hidden input control (client side). If
you need to programatically add an unknown number of hidden inputs
there is Page.RegisterHiddenField to help out.

--
Scott
http://www.OdeToCode.com/blogs/scott/

On Tue, 15 Feb 2005 13:49:50 -0600, "Keith Patrick"
<ri*******************@nospam.hotmail.com> wrote:
After completely giving up on finding some way in my ASP.Net app to take a
query string URL and redirect to it as a POST instead, I went with a system
like so:
Upon "redirection," all the QueryString pairs are placed in
HttpContext.Current.Items and retrieved with a wrapper for Request.Params
that includes checks there. This works in general instances, but one
problem has come up that has me stuck: since the stuff is in the context and
not physically presented on a page anywhere, if I move to another page and
then hit "Back," my context items are once again lost, and the page won't
display properly. Seems like the only way to persist those fields correctly
is to either put them in the query string when I go from one page to
another, which I *can't reliably do because my URLs will exceed the limit
and result in an HTTP error*, or somehow POST the variables, which I also
have not been able to do because the Request.Forms collection is read-only,
and I cannot programmatically add hidden fields to the ASP.Net form (says I
can't modify the set of controls).

So given the aforementioned scenario, is ASP.Net simply incapable of
handling this? I would think not, since Java has allowed programmatic
POSTing + it seems just too restrictive to imagine that the designers would
have made it impossible to change pages when the # of KV pairs would
potentially exceed a URL's maximum allowable length. However, I have yet to
find an actual answer to the GET-to-POST questions that have been posed (the
answers veer more towards, "just do whatever you're trying to do another
way"), and this is searching over several years of usenet posts.


Nov 19 '05 #4

P: n/a
Is it a wizard like system ?

You could also save those data in a file, a DB, a temporary session variable
etc... You could also perhaps post directly to the target page (needs a
workaround for the current form control that doesn't allow this).

Why posting those information ? Is this because yhey are inputs that would
be lost or is this to avoid reading the same data again (in the late case
they could be cached).

My personal preference is to have data processed by the page I post to but
it's likely I've been able to do this because I usually doesn't run into
some kind of process that takes several screens to be completed... (in this
case I would likely use a dataset persisted in a temporary session variable
or an XML f ile).

Patrice

--

"Keith Patrick" <ri*******************@nospam.hotmail.com> a écrit dans le
message de news:eK*************@TK2MSFTNGP09.phx.gbl...
WebClient isn't working for me because I lose my user's state information
(this is an authenticated ASP.Net app). I tried using WebClient, but it
would only take me back to the login page.
My problem is this: I need to go from page to page, but I transfer a lot of information along the way (titles of a list of one to very many items, for
example, or the item chosen). The current system uses the query string for this, but those lists of items can exceed 4k on occasion. However, I can
find no way anywhere within HttpContext.Current except for the Items
collection that can take that much information. I couldn't post the
information, as Page doesn't let me add controls to it programmatically, so I couldn't add hidden fields on submit. Request's Param collections are
read-only of course, but Response lacks Java's .SetAttribute() (IIRC) for
putting KV pairs in the POST header. Items works for the most part except
that going Back loses context and therefore all of the values stored in the Items collection. I'm against putting all data in all pages into ViewState just to help this, and ultimately what I'm trying to basically do is
programmatically move to another page with POSTed data so I can avoid the
URL length limit. I'm looking at gutting out our app's navigation system
(user controls that do a Response.Redirect that I just changed to
Server.Transfer, with *it's* own problems) and making better use of
LinkButtons and (hopefully) implicit form submittal, but I still need a
clean way of putting those values in hidden fields on the page without
manually adding them to every page in the app.

"Patrice" <no****@nowhere.com> wrote in message
news:OO**************@tk2msftngp13.phx.gbl...
It looks like you try to workaround something.

My first reaction would be to try to solve the orioginal problem rather
than
trying to workaround it (ie what exactly prevents to POST if this is what you want ?).

If you really need to post you could use WebClient to post to another page ;
there is nothing that should prevent to add hidden fields to a form and so on....

I tried to retrieve the big picture but the other post from yyou I found
doesn't seem related (was a problem with frames ?).

Patrice

--

"Keith Patrick" <ri*******************@nospam.hotmail.com> a écrit dans le message de news:OE**************@TK2MSFTNGP14.phx.gbl...
After completely giving up on finding some way in my ASP.Net app to take a
query string URL and redirect to it as a POST instead, I went with a

system
like so:
Upon "redirection," all the QueryString pairs are placed in
HttpContext.Current.Items and retrieved with a wrapper for Request.Params that includes checks there. This works in general instances, but one
problem has come up that has me stuck: since the stuff is in the context
and
not physically presented on a page anywhere, if I move to another page
and
then hit "Back," my context items are once again lost, and the page
won't display properly. Seems like the only way to persist those fields

correctly
is to either put them in the query string when I go from one page to
another, which I *can't reliably do because my URLs will exceed the limit and result in an HTTP error*, or somehow POST the variables, which I also have not been able to do because the Request.Forms collection is

read-only,
and I cannot programmatically add hidden fields to the ASP.Net form (says I
can't modify the set of controls).

So given the aforementioned scenario, is ASP.Net simply incapable of
handling this? I would think not, since Java has allowed programmatic
POSTing + it seems just too restrictive to imagine that the designers

would
have made it impossible to change pages when the # of KV pairs would
potentially exceed a URL's maximum allowable length. However, I have
yet to
find an actual answer to the GET-to-POST questions that have been posed

(the
answers veer more towards, "just do whatever you're trying to do

another way"), and this is searching over several years of usenet posts.



Nov 19 '05 #5

P: n/a
I'm posting this information because this is a navigational system where you
view reports and other tools, but each page requires certain parameters to
display their data. For instance, from the main menu, I can select a report
that takes a year and a list of school courses. With Response.Redirect, how
would the report know what the year and school courses are? We've been
using QueryString to generate the URLs, but we pass other params in that
querystring, too, so much that we're hitting the upper limit of how long a
URL can be ("out of box" options for shortening the querystring, such as
"Why don't you restrict the user's choice of courses", etc. are not an
option for the customer). I don't think Session is a particular good way to
simulate a POST, as the simple act of navigation gets much more
computationally expensive just by adding nodes to the cluster (we store
state in SQL Server). Similar reason why I don't want to pass values from
one page to another by storing it in the database: computationally expensive
hack for getting around a lack of robust POSTing functionality, ESPECIALLY
since our DB is sitting on another server. Only places I can think to store
the info are in the Request header or in ViewState so that these values
still exist when hitting "Back".
"Patrice" <no****@nowhere.com> wrote in message
news:%2****************@TK2MSFTNGP09.phx.gbl...
Is it a wizard like system ?

You could also save those data in a file, a DB, a temporary session
variable
etc... You could also perhaps post directly to the target page (needs a
workaround for the current form control that doesn't allow this).

Why posting those information ? Is this because yhey are inputs that would
be lost or is this to avoid reading the same data again (in the late case
they could be cached).

My personal preference is to have data processed by the page I post to but
it's likely I've been able to do this because I usually doesn't run into
some kind of process that takes several screens to be completed... (in
this
case I would likely use a dataset persisted in a temporary session
variable
or an XML f ile).

Patrice

--

"Keith Patrick" <ri*******************@nospam.hotmail.com> a écrit dans le
message de news:eK*************@TK2MSFTNGP09.phx.gbl...
WebClient isn't working for me because I lose my user's state information
(this is an authenticated ASP.Net app). I tried using WebClient, but it
would only take me back to the login page.
My problem is this: I need to go from page to page, but I transfer a lot

of
information along the way (titles of a list of one to very many items,
for
example, or the item chosen). The current system uses the query string

for
this, but those lists of items can exceed 4k on occasion. However, I can
find no way anywhere within HttpContext.Current except for the Items
collection that can take that much information. I couldn't post the
information, as Page doesn't let me add controls to it programmatically,

so
I couldn't add hidden fields on submit. Request's Param collections are
read-only of course, but Response lacks Java's .SetAttribute() (IIRC) for
putting KV pairs in the POST header. Items works for the most part
except
that going Back loses context and therefore all of the values stored in

the
Items collection. I'm against putting all data in all pages into

ViewState
just to help this, and ultimately what I'm trying to basically do is
programmatically move to another page with POSTed data so I can avoid the
URL length limit. I'm looking at gutting out our app's navigation system
(user controls that do a Response.Redirect that I just changed to
Server.Transfer, with *it's* own problems) and making better use of
LinkButtons and (hopefully) implicit form submittal, but I still need a
clean way of putting those values in hidden fields on the page without
manually adding them to every page in the app.

"Patrice" <no****@nowhere.com> wrote in message
news:OO**************@tk2msftngp13.phx.gbl...
> It looks like you try to workaround something.
>
> My first reaction would be to try to solve the orioginal problem rather
> than
> trying to workaround it (ie what exactly prevents to POST if this is what > you want ?).
>
> If you really need to post you could use WebClient to post to another page > ;
> there is nothing that should prevent to add hidden fields to a form and so > on....
>
> I tried to retrieve the big picture but the other post from yyou I
> found
> doesn't seem related (was a problem with frames ?).
>
> Patrice
>
> --
>
> "Keith Patrick" <ri*******************@nospam.hotmail.com> a écrit dans le > message de news:OE**************@TK2MSFTNGP14.phx.gbl...
>> After completely giving up on finding some way in my ASP.Net app to take >> a
>> query string URL and redirect to it as a POST instead, I went with a
> system
>> like so:
>> Upon "redirection," all the QueryString pairs are placed in
>> HttpContext.Current.Items and retrieved with a wrapper for Request.Params >> that includes checks there. This works in general instances, but one
>> problem has come up that has me stuck: since the stuff is in the context > and
>> not physically presented on a page anywhere, if I move to another page
>> and
>> then hit "Back," my context items are once again lost, and the page won't >> display properly. Seems like the only way to persist those fields
> correctly
>> is to either put them in the query string when I go from one page to
>> another, which I *can't reliably do because my URLs will exceed the limit >> and result in an HTTP error*, or somehow POST the variables, which I also >> have not been able to do because the Request.Forms collection is
> read-only,
>> and I cannot programmatically add hidden fields to the ASP.Net form (says > I
>> can't modify the set of controls).
>>
>> So given the aforementioned scenario, is ASP.Net simply incapable of
>> handling this? I would think not, since Java has allowed programmatic
>> POSTing + it seems just too restrictive to imagine that the designers
> would
>> have made it impossible to change pages when the # of KV pairs would
>> potentially exceed a URL's maximum allowable length. However, I have yet > to
>> find an actual answer to the GET-to-POST questions that have been
>> posed
> (the
>> answers veer more towards, "just do whatever you're trying to do another >> way"), and this is searching over several years of usenet posts.
>>
>>
>
>



Nov 19 '05 #6

P: n/a
Actually, I found your Screen Scraping article and am using that as an
informational basis to change direction. My ultimate goal is to just POST
values (since all of our pages use Request[...]). I just need the space
(and security) POSTing adds over GET, but I was coming up with umpteen
different ways to get the same effect, each with a different limitation. An
old route I had gone was the WebClient route, but I could never get the
cookie to tranfer as well, but reading your article, I see why and am
attempting to do solve the cookie issue with HttpWebRequest. Crossing my
fingers...
"Scott Allen" <sc***@nospam.odetocode.com> wrote in message
news:g9********************************@4ax.com...

Hi Keith:

I'd avoid Context.Items if you are moving from page to page - the
Items collection is only good for the duration of a single web
request.

You've ruled out view state. Other options include the Session
collection (server side) or a hidden input control (client side). If
you need to programatically add an unknown number of hidden inputs
there is Page.RegisterHiddenField to help out.

--
Scott
http://www.OdeToCode.com/blogs/scott/

On Tue, 15 Feb 2005 13:49:50 -0600, "Keith Patrick"
<ri*******************@nospam.hotmail.com> wrote:
After completely giving up on finding some way in my ASP.Net app to take a
query string URL and redirect to it as a POST instead, I went with a
system
like so:
Upon "redirection," all the QueryString pairs are placed in
HttpContext.Current.Items and retrieved with a wrapper for Request.Params
that includes checks there. This works in general instances, but one
problem has come up that has me stuck: since the stuff is in the context
and
not physically presented on a page anywhere, if I move to another page and
then hit "Back," my context items are once again lost, and the page won't
display properly. Seems like the only way to persist those fields
correctly
is to either put them in the query string when I go from one page to
another, which I *can't reliably do because my URLs will exceed the limit
and result in an HTTP error*, or somehow POST the variables, which I also
have not been able to do because the Request.Forms collection is
read-only,
and I cannot programmatically add hidden fields to the ASP.Net form (says
I
can't modify the set of controls).

So given the aforementioned scenario, is ASP.Net simply incapable of
handling this? I would think not, since Java has allowed programmatic
POSTing + it seems just too restrictive to imagine that the designers
would
have made it impossible to change pages when the # of KV pairs would
potentially exceed a URL's maximum allowable length. However, I have yet
to
find an actual answer to the GET-to-POST questions that have been posed
(the
answers veer more towards, "just do whatever you're trying to do another
way"), and this is searching over several years of usenet posts.

Nov 19 '05 #7

P: n/a
On Wed, 16 Feb 2005 13:31:08 -0600, "Keith Patrick"
<ri*******************@nospam.hotmail.com> wrote:
Actually, I found your Screen Scraping article and am using that as an
informational basis to change direction. My ultimate goal is to just POST
values (since all of our pages use Request[...]). I just need the space
(and security) POSTing adds over GET, but I was coming up with umpteen
different ways to get the same effect, each with a different limitation. An
old route I had gone was the WebClient route, but I could never get the
cookie to tranfer as well, but reading your article, I see why and am
attempting to do solve the cookie issue with HttpWebRequest. Crossing my
fingers...

Oh, very cool. Let me know if you have some success!

--
Scott
http://www.OdeToCode.com/blogs/scott/
Nov 19 '05 #8

This discussion thread is closed

Replies have been disabled for this discussion.