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.
7  2707 
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.
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.
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.
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.
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.
>>
>>
>
>
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.
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/ This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: kayodeok |
last post by:
We're Mad As Hell And We're Not Going To Take It Anymore
http://hownow.brownpau.com/index.html
The web is a mess. We're tired of this deluge of <font> tags, nested
tables, spacer GIFs, and...
|
by: .DLL hell II - The Evil Empire Strikes Back |
last post by:
I can't figure out how this side-by-side assembly stuff it
supposed to work.
I have a stack of four assemblies
A has no references
B references A & C
C References A & B
D References A, B and C...
|
by: Jim Hubbard |
last post by:
I am reposting a portion of a thread that I am involved in under a new topic
because it seems that there are still people that believe the whole "DLL
Hell" myth.
I hope I can shed some light on...
|
by: Nad |
last post by:
Hello,
dll hell has been eliminated in .NET using assembly versioning.
I am new in .NET and would like to know if there is any dll-hell-equivalent
in .NET Windows or Web development...
|
by: Nx |
last post by:
Hi
I am unpacking a list into variables, for some reason they need to be
unpacked into variable names like a0,a1,a2....upto aN whatever is
in the list.
How to create the variables dynamically...
|
by: GreatB |
last post by:
Bill Gates died in a car accident.
He found himself in Purgatory being sized up by God .
.. "Well, Bill, I'm really confused on this call. I'm
not sure whether to send you to Heaven or Hell....
|
by: Dave Sauny |
last post by:
Ok, its a friday, I'm at work and I cant get this to work:
I have 3 listboxes on one tab control page. when i select an item in
listbox1 i want whatever is selected on the other 2 listboxes...
|
by: fyleow |
last post by:
I just spent hours trying to figure out why even after I set my SQL
table attributes to UTF-8 only garbage kept adding into the database.
Apparently you need to execute "SET NAMES 'utf8'" before...
|
by: Scott M. |
last post by:
I need a little help please...
I'm simply trying to set up a very basic event for a class and then create
an event handler for that class in a Console application.
I think I'm very close, but...
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
|
by: Hystou |
last post by:
Overview:
Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows...
|
by: tracyyun |
last post by:
Dear forum friends,
With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each...
|
by: isladogs |
last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM).
In this session, we are pleased to welcome a new...
|
by: conductexam |
last post by:
I have .net C# application in which I am extracting data from word file and save it in database particularly. To store word all data as it is I am converting the whole word file firstly in HTML and...
|
by: adsilva |
last post by:
A Windows Forms form does not have the event Unload, like VB6. What one acts like?
|
by: 6302768590 |
last post by:
Hai team
i want code for transfer the data from one system to another through IP address by using C# our system has to for every 5mins then we have to update the data what the data is updated ...
| |
