You've perfectly defined my puzzle. On some pages, it recognizes the form
post. On a very small small number, it doesn't. I'm not sure the
difference, but I'm trying to figure it out now.
On 6/12/07 4:41 PM, "Claude Schneegans" <[EMAIL PROTECTED]> wrote:
>>> When index.cfm is executed, it call
>>When index.cfm is executed, it calls the appropriate template or function
based on the contents of the "page" variable
Ok, but how does it call it, how does it recognizes that it was called
with method=POST and how will it call the page using the appropriate method?
--
__
If the page, for example, is /page/memberhome/whatever
The custom 404 handler calls index.cfm
Application.cfc executes, runs the parse url function, and returns an array
in the request scope with the variables parsed out, in the above case:
Request.rq.page = memberhome
Request.rq.whatever = empt
>
> Actually, it sounds like a redirect issue. Do you have a custom 404
> error handler defined in IIS or are you using something like
> isapi-rewrite to restructure your url? If your rewrite mechanism is
> not working properly then the 404 would redirect you using a GET, not
> the original POST.
>>The application uses a function called in application.cfc to deconstruct
friendly urls into ... Well ... Not so friendly urls.
Ok, but how ist the correct template finally called by the function?
--
___
REUSE CODE! Use custom tags;
See http://www.contentbox
On 6/12/07, Claude Schneegans <[EMAIL PROTECTED]> wrote:
> >>The page I was calling:
>
> /page/memberhome/action/action/campaignid/12
>
> When I changed the form to call:
>
> /index.cfm?page=memberhome&action=action&campaignid=12
>
> It worked fine.
>
> Hmmm... Could it be some problem with the ca
>>The page I was calling:
/page/memberhome/action/action/campaignid/12
When I changed the form to call:
/index.cfm?page=memberhome&action=action&campaignid=12
It worked fine.
Hmmm... Could it be some problem with the cache?
The first address shows no parameter, so it could be interpreted as t
All right. I don't have a clue why this worked.
The application uses a function called in application.cfc to deconstruct
friendly urls into ... Well ... Not so friendly urls.
The page I was calling:
/page/memberhome/action/action/campaignid/12
When I changed the form to call:
/index.cfm?page=
In my case, the problem happens under CF5.
The problem might be occuring ever time under some circumstances, but
I've never
been able to reproduce it.
>>Now I'm eliminating
chunks of code line by line to see if I can identify a particular element
that is causing it.
Very good way to find the p
Is this perhaps not the only on the page?
-Original Message-
From: Charles Sheehan-Miles [mailto:[EMAIL PROTECTED]
Sent: Tuesday, June 12, 2007 11:14 AM
To: CF-Talk
Subject: Re: Form strangeness
Ok ... Now this is weird.
With some more exploring on this, I found that when the form is
Hmm. I'm using CFMX.
I'm getting it consistently on this particular form, but what's strange is
the form used to work -- I first observed the problem yesterday, and it has
been absolutely consistent since then.
I'm not sure what you mean about the form resubmitting itself. It's pretty
basic: fo
>>The form says POST
CGI.REQUEST_METHOD shows GET
Exactly the same problem here :-(
~|
Upgrade to Adobe ColdFusion MX7
The most significant release in over 10 years. Upgrade & see new features.
http://www.adobe.com/products/col
>>Has anyone encountered this?
Yes, from time to time.
Now you say that you are getting this error when the form resubmits itself?
This is a new element in the puzzle.
And also, you confirm that IIS received it as POST, then it looks like
the problem is CF related.
I thought that it was under I
The form says POST
CGI.REQUEST_METHOD shows GET
IIS logs show POST
Weird.
On 6/12/07 1:23 PM, "Claude Schneegans" <[EMAIL PROTECTED]> wrote:
>>> I looked through the archives and found some folks who've had the same
> problem
>
> Yeap! Can you dump CGI.REQUEST_METHOD variable and see if it con
>>I looked through the archives and found some folks who've had the same
problem
Yeap! Can you dump CGI.REQUEST_METHOD variable and see if it contains
GET or POST?
--
___
REUSE CODE! Use custom tags;
See http://www.contentbox.com/claude/customtags/tagstore.c
Hmm. Yeah -- tried that. Tried to explicitly set the encoding type.
I just went through the IIS logs, and they show the request as a POST. So
it's somewhere in the processing in the Coldfusion side. I'm banging my
head into the wall at this point.
On 6/12/07 1:09 PM, "Josh Nathanson" <[EMAIL
> Yeah, it is. Actually, it's going to the right page, but I found that for
> some reason its doing a "GET" instead of a "POST"
Did you try giving your form tag a name attribute? Shouldn't make a
difference but that's the only thing I see that's out of the ordinary.
-- Josh
Yeah, it is. Actually, it's going to the right page, but I found that for
some reason its doing a "GET" instead of a "POST"
I looked through the archives and found some folks who've had the same
problem but only with IE7. I'm hitting this on all browsers.
On 6/12/07 12:10 PM, "koen darling" <[
Ok ... Now this is weird.
With some more exploring on this, I found that when the form is submitted, I
get the following in the cgi scope:
Content_type: application/x-www-form-urlencoded
Request_method: GET
Even though the form is clearly a POST. Has anyone encountered this?
On 6/12/07 10:45
Be sure the tag, which includes "#actionpage#" is within a cfoutput
block. Take a look at the source of your form to be certain it's set to post
to the right page.
Koen
~|
Create robust enterprise, web RIAs.
Upgrade & integrate
20 matches
Mail list logo
