ASP.Net hell -> HttpContext.Items

[Keith Patrick]

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.

 

[Patrice]

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]

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.

 

[Scott Allen]

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.

 

[Patrice]

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]

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".

 

[Keith Patrick]

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]

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!