The issue mainly is that it's not always happening all the time. So it's
not
repeatable as far as I can tell.
If you have verified the code then check to see if the user in question is
running an internet security program of some kind. Many of the firewalls
they install prevent form
AAAa... There we go. That's the most logical answer (since I blocked
the error emails from that one user and when that specific error shows up
and it's been quiet).
I'll pass the word along and let him know. Thank you. :)
On Mon, Sep 22, 2014 at 12:19 PM, UXB Internet
But the correct answer is to correct the enctype so this won't be an issue.
On 9/22/14, 12:21 PM, Phillip Vector wrote:
AAAa... There we go. That's the most logical answer (since I blocked
the error emails from that one user and when that specific error shows up
and it's been quiet).
Already corrected it and it's still doing it.
I'm willing to try anything at this point.
On Mon, Sep 22, 2014 at 1:16 PM, .jonah jonah@creori.com wrote:
But the correct answer is to correct the enctype so this won't be an issue.
On 9/22/14, 12:21 PM, Phillip Vector wrote:
AAAa...
Gotit. Apologies for not tracking the thread closely.
It might be interesting to log ALL the variables in the various scopes
when that happens and see what's coming through.
Good luck!
On 9/22/14, 1:25 PM, Phillip Vector wrote:
Already corrected it and it's still doing it.
I'm willing to
Are you posting the data via AJAX? There's a known issue w/IE9 and earlier
w/AJAX POST operations, where if the server's keep alive timeout is lower
than 60 seconds, it can cause IE problems and what you get is a request
that doesn't post the data back to the server.
-Dan
On Sun, Sep 21, 2014
No. Just a straight form. No AJAX.
I THINK I traced it down to a bug in Railo in that it needs write access to
the Web-Inf directory. But we will see if the issue is solved or not later.
On Sun, Sep 21, 2014 at 8:47 AM, Dan G. Switzer, II dswit...@pengoworks.com
wrote:
Are you posting the
I don't know if this is a CFML issue or what... But perhaps someone has run
across this and can offer a hand...
form action=#myself#Login.CheckLogin method=post
enctype=multipart/form-data
input type=text name=username
input type=Password
It was just a copy over from an old form. The old login page was a combo
login/create account that had a picture upload as part of the creation
process.
I removed the enctype and I'm still getting the error.
On Sun, Sep 21, 2014 at 10:12 AM, Dave Watts dwa...@figleaf.com wrote:
I don't know
ISTR fusebox apps by default always used FormURL2Attributes tag o convert
all the form and url scope to attributes scope.
obviously it has been many many years since I looked at fusebox, although
the thought of it still makes me ill :-) but perhaps this tag kills off the
original scope in certain
The issue mainly is that it's not always happening all the time. So it's
not repeatable as far as I can tell.
On Sun, Sep 21, 2014 at 1:07 PM, Russ Michaels r...@michaels.me.uk wrote:
ISTR fusebox apps by default always used FormURL2Attributes tag o convert
all the form and url scope to
ok a few couple of reasons I can think of.
you have an un-closed tag somewhere in the form, but it doesn't always get
rendered, maybe some conditional logic causes it to only display for some
people.
Some other conditional logic that causes the page to get redirected or
reloaded, thus without
Thanks for the tips. I'll see what I can find.
On Sun, Sep 21, 2014 at 1:59 PM, Russ Michaels r...@michaels.me.uk wrote:
ok a few couple of reasons I can think of.
you have an un-closed tag somewhere in the form, but it doesn't always get
rendered, maybe some conditional logic causes it
13 matches
Mail list logo
