Re: Forms require that the request method be POST and that the t:formdata query parameter have values.
I added this solution to the FAQ: https://tapestry.apache.org/specific-errors-faq.html If anyone has a better solution (until TAP5-1733 is fixed), please share... On Jan 18, 2016 5:44 PM, "Bob Harner" wrote: > This probably deserves to be added to Tapestry's FAQ page. It's quite > common with Tapestry apps. > > If your app is on a publicly site then it is a common result of bots > crawling your site and submitting any forms that they finds. If it isn't on > a public site then it may be a browser (e.g. certain versions of Safari) > submitting the form as part of its auto-complete logic or cache-ahead > functionality. Or it could be from someone using browser developer tools to > manually convert POST forms to GET, just to see what would happen. There > are probably a few other causes as well. > > In all the scenarios I'm aware of, these errors are harmless and you > probably don't want them logged. That's not too hard. I've used the > solution described here with success: > > > http://apache-tapestry-mailing-list-archives.1045711.n5.nabble.com/Safari-for-example-browser-history-and-form-exception-td4942074.html > > > On Mon, Jan 18, 2016 at 9:46 AM, Robson Pires > wrote: > >> Hi, >> >> In one of my environments I am facing this problem: Forms require that the >> request method be POST and that the t:formdata query parameter have >> values. >> >> Any idea about what causes of this problem? >> >> Thank you, >> >> Rob Pi >> > >
Re: Forms require that the request method be POST and that the t:formdata query parameter have values.
This probably deserves to be added to Tapestry's FAQ page. It's quite common with Tapestry apps. If your app is on a publicly site then it is a common result of bots crawling your site and submitting any forms that they finds. If it isn't on a public site then it may be a browser (e.g. certain versions of Safari) submitting the form as part of its auto-complete logic or cache-ahead functionality. Or it could be from someone using browser developer tools to manually convert POST forms to GET, just to see what would happen. There are probably a few other causes as well. In all the scenarios I'm aware of, these errors are harmless and you probably don't want them logged. That's not too hard. I've used the solution described here with success: http://apache-tapestry-mailing-list-archives.1045711.n5.nabble.com/Safari-for-example-browser-history-and-form-exception-td4942074.html On Mon, Jan 18, 2016 at 9:46 AM, Robson Pires wrote: > Hi, > > In one of my environments I am facing this problem: Forms require that the > request method be POST and that the t:formdata query parameter have values. > > Any idea about what causes of this problem? > > Thank you, > > Rob Pi >
Forms require that the request method be POST and that the t:formdata query parameter have values.
Hi, In one of my environments I am facing this problem: Forms require that the request method be POST and that the t:formdata query parameter have values. Any idea about what causes of this problem? Thank you, Rob Pi
Re: [T5.4-beta-35] "Forms require that the request method be POST and that the t:formdata query parameter have values." problem + workaround
Agreed, good point.
> On 30 Sep 2015, at 3:34 am, Thiago H de Paula Figueiredo
> wrote:
>
> Hi!
>
> Very nice point. Could you please create a JIRA issue?
>
> On Tue, 29 Sep 2015 13:55:10 -0300, Cezary Biernacki
> wrote:
>
>> Hi,
>>
>> Some introduction: My users started complaining about error message "Forms
>> require that the request method be POST and that the t:formdata query
>> parameter have values.". I understand why it was raised: Tapestry 5's Form
>> component always used to complain when submit was invoked as GET operations
>> (e.g. somebody typed "http://host/mypage.myform"; URL directly in the
>> address bar) . Pre-5.4 it was not big issue, because it was rather unusual
>> to users to accidentally invoke submit URL as GET operations, as Tapestry
>> always used Redirect-After-POST approach, and submit URLs typically were
>> not saved by browsers in the history. However Tapestry 5.4 does not
>> redirect after POST in case of server-side validation errors on submitted
>> forms (e.g. password checking). IIRC, this change was introduced to avoid
>> unnecessary creation of server side sessions.
>>
>> Again, I understand that. But now submit URLs are often exposed address bar
>> (e.g. every time a user makes mistake entering password), stored in the
>> browser's history, and - most importantly - suggested by browsers when
>> users start typing the application address. I believe such behaviour leads
>> to bad usability and leaves unpleasant impression of Tapestry's
>> application. As far as I can tell there is no simple work around to avoid
>> the exception (beside totally rewriting Form component). Only way I found
>> that works reasonably well is to suppress the exception in
>> RequestExceptionHandler and perform some other action - in my case:
>> redirect to the page - see code below.
>>
>> However detecting this particular exception is tricky as it is just generic
>> RuntimeException (why?) and the message content is localised
>> (see org.apache.tapestry5.corelib.components.Form#executeStoredActions -
>> around line 700
>> https://github.com/apache/tapestry-5/blob/master/tapestry-core/src/main/java/org/apache/tapestry5/corelib/components/Form.java#L701),
>> so detecting is quite fragile.
>>
>> My questions:
>> - do you know any better way to deal with this problem?
>> - do you see any potential issues with my solution?
>>
>> And appeal to Tapestry's creators: please introduce a more specific
>> exception class and/or allow application developers to supply their own
>> strategy dealing with such situation.
>>
>> Best regards,
>> Cezary
>>
>>
>>
>> // skipped header (imports etc.)...
>>
>> public class FormPostProblemWorkaroundExceptionHandler implements
>> RequestExceptionHandler {
>>
>> private static final Logger LOGGER = LoggerFactory.getLogger
>> (FormPostProblemWorkaroundExceptionHandler.class);
>>
>> private final RequestExceptionHandler delegate;
>>
>> private final RequestGlobals requestGlobals;
>>
>> private final BaseURLSource baseURLSource;
>>
>> private final PageRenderLinkSource pageRenderLinkSource;
>>
>>
>> public FormPostProblemWorkaroundExceptionHandler(
>> final RequestExceptionHandler delegate,
>> final RequestGlobals requestGlobals,
>> final BaseURLSource baseURLSource,
>> final PageRenderLinkSource pageRenderLinkSource
>> ) {
>> this.delegate = delegate;
>> this.requestGlobals = requestGlobals;
>> this.baseURLSource = baseURLSource;
>> this.pageRenderLinkSource = pageRenderLinkSource;
>> }
>>
>> @Override
>> public void handleRequestException(final Throwable exception) throws
>> IOException
>> {
>> if (isExceptionAboutFormExpectingPostMethod(exception)) {
>> redirect(exception);
>> return;
>> }
>>
>> delegate.handleRequestException(exception);
>> }
>>
>> private boolean isExceptionAboutFormExpectingPostMethod(final Throwable
>> exception) {
>> // unfortunately, original exception is just RuntimeException and its
>> message is localised
>> // (see Tapestry message ID core-invalid-form-request), only constant
>> information is reference to t:formdata argument
>> // see org.apache.tapestry5.corelib.components.Form.executeStoredActions()
>> return exception instanceof OperationException
>> && exception.getCause() instanceof ComponentEventException
>> && exception.ge
Re: [T5.4-beta-35] "Forms require that the request method be POST and that the t:formdata query parameter have values." problem + workaround
Hi!
Very nice point. Could you please create a JIRA issue?
On Tue, 29 Sep 2015 13:55:10 -0300, Cezary Biernacki
wrote:
Hi,
Some introduction: My users started complaining about error message
"Forms
require that the request method be POST and that the t:formdata query
parameter have values.". I understand why it was raised: Tapestry 5's
Form
component always used to complain when submit was invoked as GET
operations
(e.g. somebody typed "http://host/mypage.myform"; URL directly in the
address bar) . Pre-5.4 it was not big issue, because it was rather
unusual
to users to accidentally invoke submit URL as GET operations, as Tapestry
always used Redirect-After-POST approach, and submit URLs typically were
not saved by browsers in the history. However Tapestry 5.4 does not
redirect after POST in case of server-side validation errors on submitted
forms (e.g. password checking). IIRC, this change was introduced to avoid
unnecessary creation of server side sessions.
Again, I understand that. But now submit URLs are often exposed address
bar
(e.g. every time a user makes mistake entering password), stored in the
browser's history, and - most importantly - suggested by browsers when
users start typing the application address. I believe such behaviour
leads
to bad usability and leaves unpleasant impression of Tapestry's
application. As far as I can tell there is no simple work around to avoid
the exception (beside totally rewriting Form component). Only way I
found
that works reasonably well is to suppress the exception in
RequestExceptionHandler and perform some other action - in my case:
redirect to the page - see code below.
However detecting this particular exception is tricky as it is just
generic
RuntimeException (why?) and the message content is localised
(see org.apache.tapestry5.corelib.components.Form#executeStoredActions -
around line 700
https://github.com/apache/tapestry-5/blob/master/tapestry-core/src/main/java/org/apache/tapestry5/corelib/components/Form.java#L701),
so detecting is quite fragile.
My questions:
- do you know any better way to deal with this problem?
- do you see any potential issues with my solution?
And appeal to Tapestry's creators: please introduce a more specific
exception class and/or allow application developers to supply their own
strategy dealing with such situation.
Best regards,
Cezary
// skipped header (imports etc.)...
public class FormPostProblemWorkaroundExceptionHandler implements
RequestExceptionHandler {
private static final Logger LOGGER = LoggerFactory.getLogger
(FormPostProblemWorkaroundExceptionHandler.class);
private final RequestExceptionHandler delegate;
private final RequestGlobals requestGlobals;
private final BaseURLSource baseURLSource;
private final PageRenderLinkSource pageRenderLinkSource;
public FormPostProblemWorkaroundExceptionHandler(
final RequestExceptionHandler delegate,
final RequestGlobals requestGlobals,
final BaseURLSource baseURLSource,
final PageRenderLinkSource pageRenderLinkSource
) {
this.delegate = delegate;
this.requestGlobals = requestGlobals;
this.baseURLSource = baseURLSource;
this.pageRenderLinkSource = pageRenderLinkSource;
}
@Override
public void handleRequestException(final Throwable exception) throws
IOException
{
if (isExceptionAboutFormExpectingPostMethod(exception)) {
redirect(exception);
return;
}
delegate.handleRequestException(exception);
}
private boolean isExceptionAboutFormExpectingPostMethod(final Throwable
exception) {
// unfortunately, original exception is just RuntimeException and its
message is localised
// (see Tapestry message ID core-invalid-form-request), only constant
information is reference to t:formdata argument
// see
org.apache.tapestry5.corelib.components.Form.executeStoredActions()
return exception instanceof OperationException
&& exception.getCause() instanceof ComponentEventException
&& exception.getMessage().contains(Form.FORM_DATA);
}
private void redirect(final Throwable exception) throws IOException {
final Request request = requestGlobals.getRequest();
final String failurePage = (request.getAttribute(InternalConstants.
ACTIVE_PAGE_LOADED) == null)
? null
: requestGlobals.getActivePageName();
final Response response = requestGlobals.getResponse();
if (failurePage == null) {
final String rootURL = baseURLSource.getBaseURL(request.isSecure());
LOGGER.info("Redirecting to root URL {} after '{}'", rootURL,
exception.getMessage());
response.sendRedirect(rootURL);
return;
}
final Link link = pageRenderLinkSource.createPageRenderLink(failurePage);
LOGGER.info("Redirecting to page {} after '{}'", link,
exception.getMessage());
response.sendRedirect(link);
}
}
// add this method in your AppModule class
@Decorate(serviceInterface = RequestExceptionHandler.class)
public static RequestExceptionHandler
installWorkaroundForFormPOSTProblem(
[T5.4-beta-35] "Forms require that the request method be POST and that the t:formdata query parameter have values." problem + workaround
Hi,
Some introduction: My users started complaining about error message "Forms
require that the request method be POST and that the t:formdata query
parameter have values.". I understand why it was raised: Tapestry 5's Form
component always used to complain when submit was invoked as GET operations
(e.g. somebody typed "http://host/mypage.myform"; URL directly in the
address bar) . Pre-5.4 it was not big issue, because it was rather unusual
to users to accidentally invoke submit URL as GET operations, as Tapestry
always used Redirect-After-POST approach, and submit URLs typically were
not saved by browsers in the history. However Tapestry 5.4 does not
redirect after POST in case of server-side validation errors on submitted
forms (e.g. password checking). IIRC, this change was introduced to avoid
unnecessary creation of server side sessions.
Again, I understand that. But now submit URLs are often exposed address bar
(e.g. every time a user makes mistake entering password), stored in the
browser's history, and - most importantly - suggested by browsers when
users start typing the application address. I believe such behaviour leads
to bad usability and leaves unpleasant impression of Tapestry's
application. As far as I can tell there is no simple work around to avoid
the exception (beside totally rewriting Form component). Only way I found
that works reasonably well is to suppress the exception in
RequestExceptionHandler and perform some other action - in my case:
redirect to the page - see code below.
However detecting this particular exception is tricky as it is just generic
RuntimeException (why?) and the message content is localised
(see org.apache.tapestry5.corelib.components.Form#executeStoredActions -
around line 700
https://github.com/apache/tapestry-5/blob/master/tapestry-core/src/main/java/org/apache/tapestry5/corelib/components/Form.java#L701),
so detecting is quite fragile.
My questions:
- do you know any better way to deal with this problem?
- do you see any potential issues with my solution?
And appeal to Tapestry's creators: please introduce a more specific
exception class and/or allow application developers to supply their own
strategy dealing with such situation.
Best regards,
Cezary
// skipped header (imports etc.)...
public class FormPostProblemWorkaroundExceptionHandler implements
RequestExceptionHandler {
private static final Logger LOGGER = LoggerFactory.getLogger
(FormPostProblemWorkaroundExceptionHandler.class);
private final RequestExceptionHandler delegate;
private final RequestGlobals requestGlobals;
private final BaseURLSource baseURLSource;
private final PageRenderLinkSource pageRenderLinkSource;
public FormPostProblemWorkaroundExceptionHandler(
final RequestExceptionHandler delegate,
final RequestGlobals requestGlobals,
final BaseURLSource baseURLSource,
final PageRenderLinkSource pageRenderLinkSource
) {
this.delegate = delegate;
this.requestGlobals = requestGlobals;
this.baseURLSource = baseURLSource;
this.pageRenderLinkSource = pageRenderLinkSource;
}
@Override
public void handleRequestException(final Throwable exception) throws
IOException
{
if (isExceptionAboutFormExpectingPostMethod(exception)) {
redirect(exception);
return;
}
delegate.handleRequestException(exception);
}
private boolean isExceptionAboutFormExpectingPostMethod(final Throwable
exception) {
// unfortunately, original exception is just RuntimeException and its
message is localised
// (see Tapestry message ID core-invalid-form-request), only constant
information is reference to t:formdata argument
// see org.apache.tapestry5.corelib.components.Form.executeStoredActions()
return exception instanceof OperationException
&& exception.getCause() instanceof ComponentEventException
&& exception.getMessage().contains(Form.FORM_DATA);
}
private void redirect(final Throwable exception) throws IOException {
final Request request = requestGlobals.getRequest();
final String failurePage = (request.getAttribute(InternalConstants.
ACTIVE_PAGE_LOADED) == null)
? null
: requestGlobals.getActivePageName();
final Response response = requestGlobals.getResponse();
if (failurePage == null) {
final String rootURL = baseURLSource.getBaseURL(request.isSecure());
LOGGER.info("Redirecting to root URL {} after '{}'", rootURL,
exception.getMessage());
response.sendRedirect(rootURL);
return;
}
final Link link = pageRenderLinkSource.createPageRenderLink(failurePage);
LOGGER.info("Redirecting to page {} after '{}'", link,
exception.getMessage());
response.sendRedirect(link);
}
}
// add this method in your AppModule class
@Decorate(serviceInterface = RequestExceptionHandler.class)
public static RequestExceptionHandler installWorkaroundForFormPOSTProblem(
@Nonnull final RequestExceptionHandler delegate,
@Nonnull final RequestGlobals requestGlobals,
@Nonnull final BaseURLSource ba
Re: Forms require that the request method be POST and that the t:formdata query parameter have values
On Fri, Feb 20, 2015 at 11:47 AM, Charles Karow wrote:
> We got a lot of these a few months ago, and in every case they were from
> the then-current version of Chrome:
>
> Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko)
> Chrome/39.0.2171.71 Safari/537.36
>
> At the time I interviewed a few of the users, who were using the auto-fill
> feature of the browser. I never was able to determine exactly what was
> happening, and have had to set the matter aside for other priorities.
>
So I wonder if setting the autocomplete="false" would fix this for the time
being, I have also noticed on the android phones it appears to be newer
versions of chrome too. I was just taking a look at my logs and this
exception has appear 7015 times since early fall, so I find that to be a
bit alarming.
>
> On 2/20/15 11:27 AM, George Christman wrote:
>
>> Digging deeper, looking at the form src. I'm seeing the following ex
>>
>> String[] values = request.getParameters(FORM_DATA);
>>
>> if (!request.getMethod().equals("POST") || values == null)
>> throw new RuntimeException(messages.format("core-invalid-form-request",
>> FORM_DATA));
>>
>> Is there any way to know which one of these two conditions are actually
>> causing the exception? Can you still have a post while having null
>> form_data?
>>
>> On Fri, Feb 20, 2015 at 11:09 AM, George Christman <
>> gchrist...@cardaddy.com>
>> wrote:
>>
>> I also found this article related to android. Again I'm not very familiar
>>> with this stuff, so please forgive me if it's unrelated.
>>>
>>>
>>> http://stackoverflow.com/questions/8587913/what-
>>> exactly-does-urlconnection-setdooutput-affect
>>>
>>> On Fri, Feb 20, 2015 at 11:04 AM, George Christman <
>>> gchrist...@cardaddy.com> wrote:
>>>
>>> Some further research has turned up this
http://stackoverflow.com/questions/8187188/android-4-0-
ics-turning-httpurlconnection-get-requests-into-post-requests
I also posted the following question on SO
http://stackoverflow.com/questions/28632632/browser-
turning-a-post-request-into-a-get?noredirect=1#comment45565655_28632632
Someone answered with the following answer, I'm not sure if it even
makes
sense.
The problem caused by address bar completion of all browsers and the
solution is that, please add *autocomplete="false"* to all of your
forms.
On Fri, Feb 20, 2015 at 10:38 AM, George Christman <
gchrist...@cardaddy.com> wrote:
> On Fri, Feb 20, 2015 at 9:31 AM, Thiago H de Paula Figueiredo <
> thiag...@gmail.com> wrote:
>
> On Fri, 20 Feb 2015 12:15:55 -0200, George Christman <
>> gchrist...@cardaddy.com> wrote:
>>
>> So the question is how is the user able to force the browser to load
>>
>>> that
>>> url in the address bar, "I assuming its being loaded in the address
>>> bar"?
>>> Is there a bug in the form component or could the user have some sort
>>> of
>>> browser setting causing this. Ironically I noticed a lot of ie6 users
>>> but
>>> some android users as well which this exception. Before I block the
>>> exception from clogging up my logs, I'd like to make one last attempt
>>> at
>>> resolving it.
>>>
>>> What I'd really like to know is if the app is failing do to bad code
>>> or if the user is doing something to cause it to fail.
>>>
>>> I'd guess this is caused by browsers misbehaving, specially after
>> the
>> IE6 info (who the hell still uses such an ancient and overall horrible
>> browser yet?). What else could turn a POST into a GET?
>>
>> ^^ lol, great question. I think I'm going to add a js warning for
> all xp
> users to find an alternate browser. I didn't want to support old
> versions
> of ie back then and I'm deff not doing it today lol.
>
> Do you think there is a reason for a browser to do such a thing? I'm
> assuming you don't believe it's bad code, but rather the browser
> screwing
> up.
>
> Some thoughts,
>
> Relative urls shouldn't effect this right?
>
> What about long transactions? Could a user stop, double submit etc that
> could cause the browser to screw up?
>
> --
>> Thiago H. de Paula Figueiredo
>> Tapestry, Java and Hibernate consultant and developer
>> http://machina.com.br
>>
>> -
>> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
>> For additional commands, e-mail: users-h...@tapestry.apache.org
>>
>>
>>
> --
> George Christman
> CEO
> www.CarDaddy.com
> P.O. Box 735
> Johnstown, New York
>
>
>
--
George Christman
CEO
www.CarDaddy.com
P.O. Box 735
Johnstown, New York
>>> --
>>> George Christman
>>> CEO
>>> www.CarDaddy
Re: Forms require that the request method be POST and that the t:formdata query parameter have values
We got a lot of these a few months ago, and in every case they were from
the then-current version of Chrome:
Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like
Gecko) Chrome/39.0.2171.71 Safari/537.36
At the time I interviewed a few of the users, who were using the
auto-fill feature of the browser. I never was able to determine exactly
what was happening, and have had to set the matter aside for other
priorities.
On 2/20/15 11:27 AM, George Christman wrote:
Digging deeper, looking at the form src. I'm seeing the following ex
String[] values = request.getParameters(FORM_DATA);
if (!request.getMethod().equals("POST") || values == null)
throw new RuntimeException(messages.format("core-invalid-form-request",
FORM_DATA));
Is there any way to know which one of these two conditions are actually
causing the exception? Can you still have a post while having null
form_data?
On Fri, Feb 20, 2015 at 11:09 AM, George Christman
wrote:
I also found this article related to android. Again I'm not very familiar
with this stuff, so please forgive me if it's unrelated.
http://stackoverflow.com/questions/8587913/what-exactly-does-urlconnection-setdooutput-affect
On Fri, Feb 20, 2015 at 11:04 AM, George Christman <
gchrist...@cardaddy.com> wrote:
Some further research has turned up this
http://stackoverflow.com/questions/8187188/android-4-0-ics-turning-httpurlconnection-get-requests-into-post-requests
I also posted the following question on SO
http://stackoverflow.com/questions/28632632/browser-turning-a-post-request-into-a-get?noredirect=1#comment45565655_28632632
Someone answered with the following answer, I'm not sure if it even makes
sense.
The problem caused by address bar completion of all browsers and the
solution is that, please add *autocomplete="false"* to all of your forms.
On Fri, Feb 20, 2015 at 10:38 AM, George Christman <
gchrist...@cardaddy.com> wrote:
On Fri, Feb 20, 2015 at 9:31 AM, Thiago H de Paula Figueiredo <
thiag...@gmail.com> wrote:
On Fri, 20 Feb 2015 12:15:55 -0200, George Christman <
gchrist...@cardaddy.com> wrote:
So the question is how is the user able to force the browser to load
that
url in the address bar, "I assuming its being loaded in the address
bar"?
Is there a bug in the form component or could the user have some sort
of
browser setting causing this. Ironically I noticed a lot of ie6 users
but
some android users as well which this exception. Before I block the
exception from clogging up my logs, I'd like to make one last attempt
at
resolving it.
What I'd really like to know is if the app is failing do to bad code
or if the user is doing something to cause it to fail.
I'd guess this is caused by browsers misbehaving, specially after the
IE6 info (who the hell still uses such an ancient and overall horrible
browser yet?). What else could turn a POST into a GET?
^^ lol, great question. I think I'm going to add a js warning for all xp
users to find an alternate browser. I didn't want to support old versions
of ie back then and I'm deff not doing it today lol.
Do you think there is a reason for a browser to do such a thing? I'm
assuming you don't believe it's bad code, but rather the browser screwing
up.
Some thoughts,
Relative urls shouldn't effect this right?
What about long transactions? Could a user stop, double submit etc that
could cause the browser to screw up?
--
Thiago H. de Paula Figueiredo
Tapestry, Java and Hibernate consultant and developer
http://machina.com.br
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
--
George Christman
CEO
www.CarDaddy.com
P.O. Box 735
Johnstown, New York
--
George Christman
CEO
www.CarDaddy.com
P.O. Box 735
Johnstown, New York
--
George Christman
CEO
www.CarDaddy.com
P.O. Box 735
Johnstown, New York
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Forms require that the request method be POST and that the t:formdata query parameter have values
Digging deeper, looking at the form src. I'm seeing the following ex
String[] values = request.getParameters(FORM_DATA);
if (!request.getMethod().equals("POST") || values == null)
throw new RuntimeException(messages.format("core-invalid-form-request",
FORM_DATA));
Is there any way to know which one of these two conditions are actually
causing the exception? Can you still have a post while having null
form_data?
On Fri, Feb 20, 2015 at 11:09 AM, George Christman
wrote:
> I also found this article related to android. Again I'm not very familiar
> with this stuff, so please forgive me if it's unrelated.
>
>
> http://stackoverflow.com/questions/8587913/what-exactly-does-urlconnection-setdooutput-affect
>
> On Fri, Feb 20, 2015 at 11:04 AM, George Christman <
> gchrist...@cardaddy.com> wrote:
>
>> Some further research has turned up this
>>
>>
>> http://stackoverflow.com/questions/8187188/android-4-0-ics-turning-httpurlconnection-get-requests-into-post-requests
>>
>> I also posted the following question on SO
>>
>> http://stackoverflow.com/questions/28632632/browser-turning-a-post-request-into-a-get?noredirect=1#comment45565655_28632632
>>
>> Someone answered with the following answer, I'm not sure if it even makes
>> sense.
>>
>> The problem caused by address bar completion of all browsers and the
>> solution is that, please add *autocomplete="false"* to all of your forms.
>>
>>
>>
>> On Fri, Feb 20, 2015 at 10:38 AM, George Christman <
>> gchrist...@cardaddy.com> wrote:
>>
>>>
>>>
>>> On Fri, Feb 20, 2015 at 9:31 AM, Thiago H de Paula Figueiredo <
>>> thiag...@gmail.com> wrote:
>>>
On Fri, 20 Feb 2015 12:15:55 -0200, George Christman <
gchrist...@cardaddy.com> wrote:
So the question is how is the user able to force the browser to load
> that
> url in the address bar, "I assuming its being loaded in the address
> bar"?
> Is there a bug in the form component or could the user have some sort
> of
> browser setting causing this. Ironically I noticed a lot of ie6 users
> but
> some android users as well which this exception. Before I block the
> exception from clogging up my logs, I'd like to make one last attempt
> at
> resolving it.
>
> What I'd really like to know is if the app is failing do to bad code
> or if the user is doing something to cause it to fail.
>
I'd guess this is caused by browsers misbehaving, specially after the
IE6 info (who the hell still uses such an ancient and overall horrible
browser yet?). What else could turn a POST into a GET?
>>> ^^ lol, great question. I think I'm going to add a js warning for all xp
>>> users to find an alternate browser. I didn't want to support old versions
>>> of ie back then and I'm deff not doing it today lol.
>>>
>>> Do you think there is a reason for a browser to do such a thing? I'm
>>> assuming you don't believe it's bad code, but rather the browser screwing
>>> up.
>>>
>>> Some thoughts,
>>>
>>> Relative urls shouldn't effect this right?
>>>
>>> What about long transactions? Could a user stop, double submit etc that
>>> could cause the browser to screw up?
>>>
--
Thiago H. de Paula Figueiredo
Tapestry, Java and Hibernate consultant and developer
http://machina.com.br
-
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
>>>
>>>
>>> --
>>> George Christman
>>> CEO
>>> www.CarDaddy.com
>>> P.O. Box 735
>>> Johnstown, New York
>>>
>>>
>>
>>
>> --
>> George Christman
>> CEO
>> www.CarDaddy.com
>> P.O. Box 735
>> Johnstown, New York
>>
>>
>
>
> --
> George Christman
> CEO
> www.CarDaddy.com
> P.O. Box 735
> Johnstown, New York
>
>
--
George Christman
CEO
www.CarDaddy.com
P.O. Box 735
Johnstown, New York
Re: Forms require that the request method be POST and that the t:formdata query parameter have values
I also found this article related to android. Again I'm not very familiar with this stuff, so please forgive me if it's unrelated. http://stackoverflow.com/questions/8587913/what-exactly-does-urlconnection-setdooutput-affect On Fri, Feb 20, 2015 at 11:04 AM, George Christman wrote: > Some further research has turned up this > > > http://stackoverflow.com/questions/8187188/android-4-0-ics-turning-httpurlconnection-get-requests-into-post-requests > > I also posted the following question on SO > > http://stackoverflow.com/questions/28632632/browser-turning-a-post-request-into-a-get?noredirect=1#comment45565655_28632632 > > Someone answered with the following answer, I'm not sure if it even makes > sense. > > The problem caused by address bar completion of all browsers and the > solution is that, please add *autocomplete="false"* to all of your forms. > > > > On Fri, Feb 20, 2015 at 10:38 AM, George Christman < > gchrist...@cardaddy.com> wrote: > >> >> >> On Fri, Feb 20, 2015 at 9:31 AM, Thiago H de Paula Figueiredo < >> thiag...@gmail.com> wrote: >> >>> On Fri, 20 Feb 2015 12:15:55 -0200, George Christman < >>> gchrist...@cardaddy.com> wrote: >>> >>> So the question is how is the user able to force the browser to load that url in the address bar, "I assuming its being loaded in the address bar"? Is there a bug in the form component or could the user have some sort of browser setting causing this. Ironically I noticed a lot of ie6 users but some android users as well which this exception. Before I block the exception from clogging up my logs, I'd like to make one last attempt at resolving it. What I'd really like to know is if the app is failing do to bad code or if the user is doing something to cause it to fail. >>> >>> I'd guess this is caused by browsers misbehaving, specially after the >>> IE6 info (who the hell still uses such an ancient and overall horrible >>> browser yet?). What else could turn a POST into a GET? >>> >> ^^ lol, great question. I think I'm going to add a js warning for all xp >> users to find an alternate browser. I didn't want to support old versions >> of ie back then and I'm deff not doing it today lol. >> >> Do you think there is a reason for a browser to do such a thing? I'm >> assuming you don't believe it's bad code, but rather the browser screwing >> up. >> >> Some thoughts, >> >> Relative urls shouldn't effect this right? >> >> What about long transactions? Could a user stop, double submit etc that >> could cause the browser to screw up? >> >>> >>> -- >>> Thiago H. de Paula Figueiredo >>> Tapestry, Java and Hibernate consultant and developer >>> http://machina.com.br >>> >>> - >>> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org >>> For additional commands, e-mail: users-h...@tapestry.apache.org >>> >>> >> >> >> -- >> George Christman >> CEO >> www.CarDaddy.com >> P.O. Box 735 >> Johnstown, New York >> >> > > > -- > George Christman > CEO > www.CarDaddy.com > P.O. Box 735 > Johnstown, New York > > -- George Christman CEO www.CarDaddy.com P.O. Box 735 Johnstown, New York
Re: Forms require that the request method be POST and that the t:formdata query parameter have values
Some further research has turned up this http://stackoverflow.com/questions/8187188/android-4-0-ics-turning-httpurlconnection-get-requests-into-post-requests I also posted the following question on SO http://stackoverflow.com/questions/28632632/browser-turning-a-post-request-into-a-get?noredirect=1#comment45565655_28632632 Someone answered with the following answer, I'm not sure if it even makes sense. The problem caused by address bar completion of all browsers and the solution is that, please add *autocomplete="false"* to all of your forms. On Fri, Feb 20, 2015 at 10:38 AM, George Christman wrote: > > > On Fri, Feb 20, 2015 at 9:31 AM, Thiago H de Paula Figueiredo < > thiag...@gmail.com> wrote: > >> On Fri, 20 Feb 2015 12:15:55 -0200, George Christman < >> gchrist...@cardaddy.com> wrote: >> >> So the question is how is the user able to force the browser to load that >>> url in the address bar, "I assuming its being loaded in the address bar"? >>> Is there a bug in the form component or could the user have some sort of >>> browser setting causing this. Ironically I noticed a lot of ie6 users but >>> some android users as well which this exception. Before I block the >>> exception from clogging up my logs, I'd like to make one last attempt at >>> resolving it. >>> >>> What I'd really like to know is if the app is failing do to bad code or >>> if the user is doing something to cause it to fail. >>> >> >> I'd guess this is caused by browsers misbehaving, specially after the IE6 >> info (who the hell still uses such an ancient and overall horrible browser >> yet?). What else could turn a POST into a GET? >> > ^^ lol, great question. I think I'm going to add a js warning for all xp > users to find an alternate browser. I didn't want to support old versions > of ie back then and I'm deff not doing it today lol. > > Do you think there is a reason for a browser to do such a thing? I'm > assuming you don't believe it's bad code, but rather the browser screwing > up. > > Some thoughts, > > Relative urls shouldn't effect this right? > > What about long transactions? Could a user stop, double submit etc that > could cause the browser to screw up? > >> >> -- >> Thiago H. de Paula Figueiredo >> Tapestry, Java and Hibernate consultant and developer >> http://machina.com.br >> >> - >> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org >> For additional commands, e-mail: users-h...@tapestry.apache.org >> >> > > > -- > George Christman > CEO > www.CarDaddy.com > P.O. Box 735 > Johnstown, New York > > -- George Christman CEO www.CarDaddy.com P.O. Box 735 Johnstown, New York
Re: Forms require that the request method be POST and that the t:formdata query parameter have values
On Fri, Feb 20, 2015 at 9:31 AM, Thiago H de Paula Figueiredo < thiag...@gmail.com> wrote: > On Fri, 20 Feb 2015 12:15:55 -0200, George Christman < > gchrist...@cardaddy.com> wrote: > > So the question is how is the user able to force the browser to load that >> url in the address bar, "I assuming its being loaded in the address bar"? >> Is there a bug in the form component or could the user have some sort of >> browser setting causing this. Ironically I noticed a lot of ie6 users but >> some android users as well which this exception. Before I block the >> exception from clogging up my logs, I'd like to make one last attempt at >> resolving it. >> >> What I'd really like to know is if the app is failing do to bad code or >> if the user is doing something to cause it to fail. >> > > I'd guess this is caused by browsers misbehaving, specially after the IE6 > info (who the hell still uses such an ancient and overall horrible browser > yet?). What else could turn a POST into a GET? > ^^ lol, great question. I think I'm going to add a js warning for all xp users to find an alternate browser. I didn't want to support old versions of ie back then and I'm deff not doing it today lol. Do you think there is a reason for a browser to do such a thing? I'm assuming you don't believe it's bad code, but rather the browser screwing up. Some thoughts, Relative urls shouldn't effect this right? What about long transactions? Could a user stop, double submit etc that could cause the browser to screw up? > > -- > Thiago H. de Paula Figueiredo > Tapestry, Java and Hibernate consultant and developer > http://machina.com.br > > - > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > For additional commands, e-mail: users-h...@tapestry.apache.org > > -- George Christman CEO www.CarDaddy.com P.O. Box 735 Johnstown, New York
Re: Forms require that the request method be POST and that the t:formdata query parameter have values
On Fri, 20 Feb 2015 12:15:55 -0200, George Christman wrote: So the question is how is the user able to force the browser to load that url in the address bar, "I assuming its being loaded in the address bar"? Is there a bug in the form component or could the user have some sort of browser setting causing this. Ironically I noticed a lot of ie6 users but some android users as well which this exception. Before I block the exception from clogging up my logs, I'd like to make one last attempt at resolving it. What I'd really like to know is if the app is failing do to bad code or if the user is doing something to cause it to fail. I'd guess this is caused by browsers misbehaving, specially after the IE6 info (who the hell still uses such an ancient and overall horrible browser yet?). What else could turn a POST into a GET? -- Thiago H. de Paula Figueiredo Tapestry, Java and Hibernate consultant and developer http://machina.com.br - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Forms require that the request method be POST and that the t:formdata query parameter have values
I know this has been an on going topic, but I have yet to see a solid solution for this, so I'm re-posting the question with some additional information. Myself as well as many others have seen the following exception popup numerous times. Forms require that the request method be POST and that the t:formdata query parameter have values It's always been thought to have been caused by bot activity, however I see it happening behind firewalls etc. I recently started logging the URI and User Agent to help determine the cause of the exception and what I found was what appeared to be real users experiencing the error. Some examples. Example 1 *URI - *https://www.domain.com/vehicles/index.sortform *User Agent - * mozilla/4.0 (compatible; msie 6.0; windows nt 5.1; sv1; .net clr 2.0.50727; .net clr 3.0.4506.2152; .net clr 3.5.30729) org.apache.tapestry5.ioc. internal.OperationException: Forms require that the request method be POST and that the t:formdata query parameter have values. [at classpath:com/domain/auto/pages/vehicles/VehiclesIndex.tml, line 29 Example 2 *URI - *https://www.domain.com/vehicles/index.menuform *User Agent - * mozilla/5.0 (linux; android 4.4.4; en-us; samsung sm-n900p build/ktu84p) applewebkit/537.36 (khtml, like gecko) version/1.5 chrome/28.0.1500.94 mobile safari/537.36 org.apache.tapestry5.ioc. internal.OperationException: Forms require that the request method be POST and that the t:formdata query parameter have values. [at classpath:com/domain/auto/pages/vehicles/VehiclesIndex.tml, line 26] at *Example 3* URI - https://www.domain.com/vehicles/index.menuform User Agent - mozilla/5.0 (linux; android 4.4.2; sch-i545 build/kot49h) applewebkit/537.36 (khtml, like gecko) chrome/39.0.2171.93 mobile safari/537.36 org.apache.tapestry5.ioc. internal.OperationException: Forms require that the request method be POST and that the t:formdata query parameter have values. [at classpath:com/domain/auto/pages/vehicles/VehiclesIndex.tml, line 26] at So the question is how is the user able to force the browser to load that url in the address bar, "I assuming its being loaded in the address bar"? Is there a bug in the form component or could the user have some sort of browser setting causing this. Ironically I noticed a lot of ie6 users but some android users as well which this exception. Before I block the exception from clogging up my logs, I'd like to make one last attempt at resolving it. What I'd really like to know is if the app is failing do to bad code or if the user is doing something to cause it to fail. Thanks
Re: Forms require that the request method be POST and that the t:formdata query parameter have values
Most likely a bot crawling your site. You may choose to suppress this logging for crawlers. This can be done by maintaining a list of crawler user agents and checking the user agent request header before logging.
Re: Forms require that the request method be POST and that the t:formdata query parameter have values
Hi, That could be an autocomplete feature of browser's address bar -- which autocompletes form's submission URL. Or it could be that user submits a form and it takes too long to process it, and during that time user clicks to browser's address bar and hits Enter (which issues HTTP GET request). On Mon, Sep 8, 2014 at 1:17 PM, Marcel Huber wrote: > Hi, > > We use Tapestry 5.2.6 and we have this Exception quite often in our logs: > [2014-09-07 21:18:27,951][ERROR] AppModuleBase.FFRequestExceptionHandler > [qe-shop] Processing of request failed with uncaught exception: Forms > require that the request method be POST and that the t:formdata query > parameter have values. > org.apache.tapestry5.ioc.internal.OperationException: Forms require that > the request method be POST and that the t:formdata query parameter have > values. [at > classpath:ch/fashionfriends/client/http/pages/checkout/CheckoutBasket.tml, > line 11] > at > > org.apache.tapestry5.ioc.internal.OperationTrackerImpl.logAndRethrow(OperationTrackerImpl.java:102)… > … > [2014-09-07 21:18:27,955][ERROR] layout.ExceptionReportHandler [qe-shop] > ffReportException: [org.apache.tapestry5.ioc.internal.OperationException: > Forms require that the request method be POST and that the t:formdata query > parameter have values. [at > classpath:ch/fashionfriends/client/http/pages/checkout/CheckoutBasket.tml, > line 11]] caused by uri [/de/checkout/basket.basketform] [MUser [@7ada6333] > artificialId=2efaf248-1f54-4b2e-afe5-dbcdcc3c1609, > instanceId=ClientID[748], lastInstanceUpdate=1410116735467>, firstName=, > middleName=, lastName=, roles=null, loggedIn=false>] User-Agent > [Mozilla/5.0 (Linux; U; Android 4.1.2; de-de; GT-I8190N Build/JZO54K) > AppleWebKit/534.30 (KHTML, like Gecko) Version/4.0 Mobile Safari/534.30] > Referer [null] > > We can't explain, where this exception is comming from and how to fix it. > All we know is, there are mostly Safari user and it happens on all forms > and it's not bot problem. > > Does anybody have a idee what that is and what we can do to fix it? > > thx > > -- > Marcel > owns his style. > > Application Engineer > -- Dmitry Gusev AnjLab Team http://anjlab.com
Forms require that the request method be POST and that the t:formdata query parameter have values
Hi, We use Tapestry 5.2.6 and we have this Exception quite often in our logs: [2014-09-07 21:18:27,951][ERROR] AppModuleBase.FFRequestExceptionHandler [qe-shop] Processing of request failed with uncaught exception: Forms require that the request method be POST and that the t:formdata query parameter have values. org.apache.tapestry5.ioc.internal.OperationException: Forms require that the request method be POST and that the t:formdata query parameter have values. [at classpath:ch/fashionfriends/client/http/pages/checkout/CheckoutBasket.tml, line 11] at org.apache.tapestry5.ioc.internal.OperationTrackerImpl.logAndRethrow(OperationTrackerImpl.java:102)… … [2014-09-07 21:18:27,955][ERROR] layout.ExceptionReportHandler [qe-shop] ffReportException: [org.apache.tapestry5.ioc.internal.OperationException: Forms require that the request method be POST and that the t:formdata query parameter have values. [at classpath:ch/fashionfriends/client/http/pages/checkout/CheckoutBasket.tml, line 11]] caused by uri [/de/checkout/basket.basketform] [MUser [@7ada6333] , firstName=, middleName=, lastName=, roles=null, loggedIn=false>] User-Agent [Mozilla/5.0 (Linux; U; Android 4.1.2; de-de; GT-I8190N Build/JZO54K) AppleWebKit/534.30 (KHTML, like Gecko) Version/4.0 Mobile Safari/534.30] Referer [null] We can't explain, where this exception is comming from and how to fix it. All we know is, there are mostly Safari user and it happens on all forms and it's not bot problem. Does anybody have a idee what that is and what we can do to fix it? thx -- Marcel owns his style. Application Engineer
Re: Forms require that the request method be POST
That depends on if the page containing the form and/or form handlers @RequiresAuthentication or @RequiresUser. On Wed, Jun 25, 2014 at 10:49 PM, George Christman wrote: > Okay cool, that works too. Now if I'm setting remember me to true, should I > still be seeing this exception? > > > On Wed, Jun 25, 2014 at 2:44 PM, Dmitry Gusev > wrote: > > > It won't continue form submission, user will be redirected to the page > with > > empty form. > > > > > > On Wed, Jun 25, 2014 at 10:31 PM, George Christman < > > gchrist...@cardaddy.com> > > wrote: > > > > > Thanks Dmitry, I'm willing to give it a shot. What outcome should I > > expect > > > to see from your code? Will it just bring the user back to a blank > form, > > or > > > will it continue with the form submission? > > > > > > > > > On Wed, Jun 25, 2014 at 1:56 PM, Dmitry Gusev > > > wrote: > > > > > > > Hi George, > > > > > > > > See one possible solution here: > > > > > > > > > > https://github.com/tynamo/tapestry-security/issues/7#issuecomment-40301795 > > > > > > > > > > > > On Wed, Jun 25, 2014 at 7:36 PM, George Christman < > > > gchrist...@cardaddy.com > > > > > > > > > wrote: > > > > > > > > > So I finally figured out how to reproduce this exception. I'm using > > > > > Tapestry-Security and if the session times out and the user submits > > the > > > > > form, the page is redirected to the login page. When the user logs > > in, > > > it > > > > > attempts to resubmit the form and ends with this exception. Does > > > anybody > > > > > know how to handle this? > > > > > > > > > > > > > > > On Mon, May 19, 2014 at 10:53 PM, George Christman < > > > > > gchrist...@cardaddy.com> > > > > > wrote: > > > > > > > > > > > Thanks for the tips guys, I'll see if I can find the culprit now > > > that I > > > > > > know why it's happening. > > > > > > > > > > > > > > > > > > On Mon, May 19, 2014 at 5:52 PM, Eugen > > wrote: > > > > > > > > > > > >> Hi, I have had this kind of exception then i tried to submit a > > form > > > > > >> programmatically from an Applet (HttpClient) without sending the > > > > > >> formData field. > > > > > >> > > > > > >> 2014-05-19 22:31 GMT+02:00 Kristian Marinkovic < > > > > > >> kristian.marinko...@gmail.com>: > > > > > >> > Hi, > > > > > >> > > > > > > >> > check if it is the same client. i once had the same problem. > > After > > > > > >> several > > > > > >> > hours of investigation it was a developer with a browser > plugin > > > (web > > > > > >> > developer) which enabled converting form post requests to get > > > > > requests. > > > > > >> > > > > > > >> > hope this helps. > > > > > >> > > > > > > >> > g, > > > > > >> > Kris > > > > > >> > > > > > > >> > > > > > > >> > On Mon, May 19, 2014 at 5:55 PM, George Christman > > > > > >> > wrote: > > > > > >> > > > > > > >> >> Let me do some more homework now that I at least now how it's > > > > thrown. > > > > > >> >> Thanks Thiago. > > > > > >> >> > > > > > >> >> > > > > > >> >> On Mon, May 19, 2014 at 10:54 AM, Thiago H de Paula > Figueiredo > > < > > > > > >> >> thiag...@gmail.com> wrote: > > > > > >> >> > > > > > >> >> > On Mon, 19 May 2014 11:44:06 -0300, George Christman < > > > > > >> >> > gchrist...@cardaddy.com> wrote: > > > > > >> >> > > > > > > >> >> > In this particular case the application sits behind a > > firewall > > > > > with > > > > > >> no > > > > > >> >> >> public access so I don't believe this is bot activity. Do > > you > > > > > have > > > > > >> any > > > > > >> >> >> other thoughts? > > > > > >> >> >> > > > > > >> >> > > > > > > >> >> > Do you have any information on when this exception actually > > > > > happens? > > > > > >> >> > Otherwise, we can only guess. That exception usually > happens > > > > when a > > > > > >> >> > Tapestry form URL is requested without the form fields, > hence > > > the > > > > > bot > > > > > >> >> > suspicion. > > > > > >> >> > > > > > > >> >> > > > > > > >> >> > -- > > > > > >> >> > Thiago H. de Paula Figueiredo > > > > > >> >> > Tapestry, Java and Hibernate consultant and developer > > > > > >> >> > http://machina.com.br > > > > > >> >> > > > > > > >> >> > > > > > > > - > > > > > >> >> > To unsubscribe, e-mail: > > users-unsubscr...@tapestry.apache.org > > > > > >> >> > For additional commands, e-mail: > > > users-h...@tapestry.apache.org > > > > > >> >> > > > > > > >> >> > > > > > > >> >> > > > > > >> >> > > > > > >> >> -- > > > > > >> >> George Christman > > > > > >> >> www.CarDaddy.com > > > > > >> >> P.O. Box 735 > > > > > >> >> Johnstown, New York > > > > > >> >> > > > > > >> > > > > > >> > > > - > > > > > >> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > > > > > >> For additional commands, e-mail: users-h...@tapestry.apache.org > > > > > >> > > > > > >> > > > > > > > > > > > > > > > > > > -- > > > > > > George Christman > > > > > > www.CarDaddy.com > > > > > >
Re: Forms require that the request method be POST
Okay cool, that works too. Now if I'm setting remember me to true, should I still be seeing this exception? On Wed, Jun 25, 2014 at 2:44 PM, Dmitry Gusev wrote: > It won't continue form submission, user will be redirected to the page with > empty form. > > > On Wed, Jun 25, 2014 at 10:31 PM, George Christman < > gchrist...@cardaddy.com> > wrote: > > > Thanks Dmitry, I'm willing to give it a shot. What outcome should I > expect > > to see from your code? Will it just bring the user back to a blank form, > or > > will it continue with the form submission? > > > > > > On Wed, Jun 25, 2014 at 1:56 PM, Dmitry Gusev > > wrote: > > > > > Hi George, > > > > > > See one possible solution here: > > > > > > https://github.com/tynamo/tapestry-security/issues/7#issuecomment-40301795 > > > > > > > > > On Wed, Jun 25, 2014 at 7:36 PM, George Christman < > > gchrist...@cardaddy.com > > > > > > > wrote: > > > > > > > So I finally figured out how to reproduce this exception. I'm using > > > > Tapestry-Security and if the session times out and the user submits > the > > > > form, the page is redirected to the login page. When the user logs > in, > > it > > > > attempts to resubmit the form and ends with this exception. Does > > anybody > > > > know how to handle this? > > > > > > > > > > > > On Mon, May 19, 2014 at 10:53 PM, George Christman < > > > > gchrist...@cardaddy.com> > > > > wrote: > > > > > > > > > Thanks for the tips guys, I'll see if I can find the culprit now > > that I > > > > > know why it's happening. > > > > > > > > > > > > > > > On Mon, May 19, 2014 at 5:52 PM, Eugen > wrote: > > > > > > > > > >> Hi, I have had this kind of exception then i tried to submit a > form > > > > >> programmatically from an Applet (HttpClient) without sending the > > > > >> formData field. > > > > >> > > > > >> 2014-05-19 22:31 GMT+02:00 Kristian Marinkovic < > > > > >> kristian.marinko...@gmail.com>: > > > > >> > Hi, > > > > >> > > > > > >> > check if it is the same client. i once had the same problem. > After > > > > >> several > > > > >> > hours of investigation it was a developer with a browser plugin > > (web > > > > >> > developer) which enabled converting form post requests to get > > > > requests. > > > > >> > > > > > >> > hope this helps. > > > > >> > > > > > >> > g, > > > > >> > Kris > > > > >> > > > > > >> > > > > > >> > On Mon, May 19, 2014 at 5:55 PM, George Christman > > > > >> > wrote: > > > > >> > > > > > >> >> Let me do some more homework now that I at least now how it's > > > thrown. > > > > >> >> Thanks Thiago. > > > > >> >> > > > > >> >> > > > > >> >> On Mon, May 19, 2014 at 10:54 AM, Thiago H de Paula Figueiredo > < > > > > >> >> thiag...@gmail.com> wrote: > > > > >> >> > > > > >> >> > On Mon, 19 May 2014 11:44:06 -0300, George Christman < > > > > >> >> > gchrist...@cardaddy.com> wrote: > > > > >> >> > > > > > >> >> > In this particular case the application sits behind a > firewall > > > > with > > > > >> no > > > > >> >> >> public access so I don't believe this is bot activity. Do > you > > > > have > > > > >> any > > > > >> >> >> other thoughts? > > > > >> >> >> > > > > >> >> > > > > > >> >> > Do you have any information on when this exception actually > > > > happens? > > > > >> >> > Otherwise, we can only guess. That exception usually happens > > > when a > > > > >> >> > Tapestry form URL is requested without the form fields, hence > > the > > > > bot > > > > >> >> > suspicion. > > > > >> >> > > > > > >> >> > > > > > >> >> > -- > > > > >> >> > Thiago H. de Paula Figueiredo > > > > >> >> > Tapestry, Java and Hibernate consultant and developer > > > > >> >> > http://machina.com.br > > > > >> >> > > > > > >> >> > > > > > - > > > > >> >> > To unsubscribe, e-mail: > users-unsubscr...@tapestry.apache.org > > > > >> >> > For additional commands, e-mail: > > users-h...@tapestry.apache.org > > > > >> >> > > > > > >> >> > > > > > >> >> > > > > >> >> > > > > >> >> -- > > > > >> >> George Christman > > > > >> >> www.CarDaddy.com > > > > >> >> P.O. Box 735 > > > > >> >> Johnstown, New York > > > > >> >> > > > > >> > > > > >> > > - > > > > >> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > > > > >> For additional commands, e-mail: users-h...@tapestry.apache.org > > > > >> > > > > >> > > > > > > > > > > > > > > > -- > > > > > George Christman > > > > > www.CarDaddy.com > > > > > P.O. Box 735 > > > > > Johnstown, New York > > > > > > > > > > > > > > > > > > > > > > -- > > > > George Christman > > > > www.CarDaddy.com > > > > P.O. Box 735 > > > > Johnstown, New York > > > > > > > > > > > > > > > > -- > > > Dmitry Gusev > > > > > > AnjLab Team > > > http://anjlab.com > > > > > > > > > > > -- > > George Christman > > www.CarDaddy.com > > P.O. Box 735 > > Johnstown, New York > > > > > > -- > Dmitry Gusev > > AnjLab Team > http://anjlab.com > -- George Christman www
Re: Forms require that the request method be POST
It won't continue form submission, user will be redirected to the page with empty form. On Wed, Jun 25, 2014 at 10:31 PM, George Christman wrote: > Thanks Dmitry, I'm willing to give it a shot. What outcome should I expect > to see from your code? Will it just bring the user back to a blank form, or > will it continue with the form submission? > > > On Wed, Jun 25, 2014 at 1:56 PM, Dmitry Gusev > wrote: > > > Hi George, > > > > See one possible solution here: > > > https://github.com/tynamo/tapestry-security/issues/7#issuecomment-40301795 > > > > > > On Wed, Jun 25, 2014 at 7:36 PM, George Christman < > gchrist...@cardaddy.com > > > > > wrote: > > > > > So I finally figured out how to reproduce this exception. I'm using > > > Tapestry-Security and if the session times out and the user submits the > > > form, the page is redirected to the login page. When the user logs in, > it > > > attempts to resubmit the form and ends with this exception. Does > anybody > > > know how to handle this? > > > > > > > > > On Mon, May 19, 2014 at 10:53 PM, George Christman < > > > gchrist...@cardaddy.com> > > > wrote: > > > > > > > Thanks for the tips guys, I'll see if I can find the culprit now > that I > > > > know why it's happening. > > > > > > > > > > > > On Mon, May 19, 2014 at 5:52 PM, Eugen wrote: > > > > > > > >> Hi, I have had this kind of exception then i tried to submit a form > > > >> programmatically from an Applet (HttpClient) without sending the > > > >> formData field. > > > >> > > > >> 2014-05-19 22:31 GMT+02:00 Kristian Marinkovic < > > > >> kristian.marinko...@gmail.com>: > > > >> > Hi, > > > >> > > > > >> > check if it is the same client. i once had the same problem. After > > > >> several > > > >> > hours of investigation it was a developer with a browser plugin > (web > > > >> > developer) which enabled converting form post requests to get > > > requests. > > > >> > > > > >> > hope this helps. > > > >> > > > > >> > g, > > > >> > Kris > > > >> > > > > >> > > > > >> > On Mon, May 19, 2014 at 5:55 PM, George Christman > > > >> > wrote: > > > >> > > > > >> >> Let me do some more homework now that I at least now how it's > > thrown. > > > >> >> Thanks Thiago. > > > >> >> > > > >> >> > > > >> >> On Mon, May 19, 2014 at 10:54 AM, Thiago H de Paula Figueiredo < > > > >> >> thiag...@gmail.com> wrote: > > > >> >> > > > >> >> > On Mon, 19 May 2014 11:44:06 -0300, George Christman < > > > >> >> > gchrist...@cardaddy.com> wrote: > > > >> >> > > > > >> >> > In this particular case the application sits behind a firewall > > > with > > > >> no > > > >> >> >> public access so I don't believe this is bot activity. Do you > > > have > > > >> any > > > >> >> >> other thoughts? > > > >> >> >> > > > >> >> > > > > >> >> > Do you have any information on when this exception actually > > > happens? > > > >> >> > Otherwise, we can only guess. That exception usually happens > > when a > > > >> >> > Tapestry form URL is requested without the form fields, hence > the > > > bot > > > >> >> > suspicion. > > > >> >> > > > > >> >> > > > > >> >> > -- > > > >> >> > Thiago H. de Paula Figueiredo > > > >> >> > Tapestry, Java and Hibernate consultant and developer > > > >> >> > http://machina.com.br > > > >> >> > > > > >> >> > > > > - > > > >> >> > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > > > >> >> > For additional commands, e-mail: > users-h...@tapestry.apache.org > > > >> >> > > > > >> >> > > > > >> >> > > > >> >> > > > >> >> -- > > > >> >> George Christman > > > >> >> www.CarDaddy.com > > > >> >> P.O. Box 735 > > > >> >> Johnstown, New York > > > >> >> > > > >> > > > >> > - > > > >> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > > > >> For additional commands, e-mail: users-h...@tapestry.apache.org > > > >> > > > >> > > > > > > > > > > > > -- > > > > George Christman > > > > www.CarDaddy.com > > > > P.O. Box 735 > > > > Johnstown, New York > > > > > > > > > > > > > > > > > -- > > > George Christman > > > www.CarDaddy.com > > > P.O. Box 735 > > > Johnstown, New York > > > > > > > > > > > -- > > Dmitry Gusev > > > > AnjLab Team > > http://anjlab.com > > > > > > -- > George Christman > www.CarDaddy.com > P.O. Box 735 > Johnstown, New York > -- Dmitry Gusev AnjLab Team http://anjlab.com
Re: Forms require that the request method be POST
Thanks Dmitry, I'm willing to give it a shot. What outcome should I expect to see from your code? Will it just bring the user back to a blank form, or will it continue with the form submission? On Wed, Jun 25, 2014 at 1:56 PM, Dmitry Gusev wrote: > Hi George, > > See one possible solution here: > https://github.com/tynamo/tapestry-security/issues/7#issuecomment-40301795 > > > On Wed, Jun 25, 2014 at 7:36 PM, George Christman > > wrote: > > > So I finally figured out how to reproduce this exception. I'm using > > Tapestry-Security and if the session times out and the user submits the > > form, the page is redirected to the login page. When the user logs in, it > > attempts to resubmit the form and ends with this exception. Does anybody > > know how to handle this? > > > > > > On Mon, May 19, 2014 at 10:53 PM, George Christman < > > gchrist...@cardaddy.com> > > wrote: > > > > > Thanks for the tips guys, I'll see if I can find the culprit now that I > > > know why it's happening. > > > > > > > > > On Mon, May 19, 2014 at 5:52 PM, Eugen wrote: > > > > > >> Hi, I have had this kind of exception then i tried to submit a form > > >> programmatically from an Applet (HttpClient) without sending the > > >> formData field. > > >> > > >> 2014-05-19 22:31 GMT+02:00 Kristian Marinkovic < > > >> kristian.marinko...@gmail.com>: > > >> > Hi, > > >> > > > >> > check if it is the same client. i once had the same problem. After > > >> several > > >> > hours of investigation it was a developer with a browser plugin (web > > >> > developer) which enabled converting form post requests to get > > requests. > > >> > > > >> > hope this helps. > > >> > > > >> > g, > > >> > Kris > > >> > > > >> > > > >> > On Mon, May 19, 2014 at 5:55 PM, George Christman > > >> > wrote: > > >> > > > >> >> Let me do some more homework now that I at least now how it's > thrown. > > >> >> Thanks Thiago. > > >> >> > > >> >> > > >> >> On Mon, May 19, 2014 at 10:54 AM, Thiago H de Paula Figueiredo < > > >> >> thiag...@gmail.com> wrote: > > >> >> > > >> >> > On Mon, 19 May 2014 11:44:06 -0300, George Christman < > > >> >> > gchrist...@cardaddy.com> wrote: > > >> >> > > > >> >> > In this particular case the application sits behind a firewall > > with > > >> no > > >> >> >> public access so I don't believe this is bot activity. Do you > > have > > >> any > > >> >> >> other thoughts? > > >> >> >> > > >> >> > > > >> >> > Do you have any information on when this exception actually > > happens? > > >> >> > Otherwise, we can only guess. That exception usually happens > when a > > >> >> > Tapestry form URL is requested without the form fields, hence the > > bot > > >> >> > suspicion. > > >> >> > > > >> >> > > > >> >> > -- > > >> >> > Thiago H. de Paula Figueiredo > > >> >> > Tapestry, Java and Hibernate consultant and developer > > >> >> > http://machina.com.br > > >> >> > > > >> >> > > > - > > >> >> > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > > >> >> > For additional commands, e-mail: users-h...@tapestry.apache.org > > >> >> > > > >> >> > > > >> >> > > >> >> > > >> >> -- > > >> >> George Christman > > >> >> www.CarDaddy.com > > >> >> P.O. Box 735 > > >> >> Johnstown, New York > > >> >> > > >> > > >> - > > >> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > > >> For additional commands, e-mail: users-h...@tapestry.apache.org > > >> > > >> > > > > > > > > > -- > > > George Christman > > > www.CarDaddy.com > > > P.O. Box 735 > > > Johnstown, New York > > > > > > > > > > > > -- > > George Christman > > www.CarDaddy.com > > P.O. Box 735 > > Johnstown, New York > > > > > > -- > Dmitry Gusev > > AnjLab Team > http://anjlab.com > -- George Christman www.CarDaddy.com P.O. Box 735 Johnstown, New York
Re: Forms require that the request method be POST
Hi George, See one possible solution here: https://github.com/tynamo/tapestry-security/issues/7#issuecomment-40301795 On Wed, Jun 25, 2014 at 7:36 PM, George Christman wrote: > So I finally figured out how to reproduce this exception. I'm using > Tapestry-Security and if the session times out and the user submits the > form, the page is redirected to the login page. When the user logs in, it > attempts to resubmit the form and ends with this exception. Does anybody > know how to handle this? > > > On Mon, May 19, 2014 at 10:53 PM, George Christman < > gchrist...@cardaddy.com> > wrote: > > > Thanks for the tips guys, I'll see if I can find the culprit now that I > > know why it's happening. > > > > > > On Mon, May 19, 2014 at 5:52 PM, Eugen wrote: > > > >> Hi, I have had this kind of exception then i tried to submit a form > >> programmatically from an Applet (HttpClient) without sending the > >> formData field. > >> > >> 2014-05-19 22:31 GMT+02:00 Kristian Marinkovic < > >> kristian.marinko...@gmail.com>: > >> > Hi, > >> > > >> > check if it is the same client. i once had the same problem. After > >> several > >> > hours of investigation it was a developer with a browser plugin (web > >> > developer) which enabled converting form post requests to get > requests. > >> > > >> > hope this helps. > >> > > >> > g, > >> > Kris > >> > > >> > > >> > On Mon, May 19, 2014 at 5:55 PM, George Christman > >> > wrote: > >> > > >> >> Let me do some more homework now that I at least now how it's thrown. > >> >> Thanks Thiago. > >> >> > >> >> > >> >> On Mon, May 19, 2014 at 10:54 AM, Thiago H de Paula Figueiredo < > >> >> thiag...@gmail.com> wrote: > >> >> > >> >> > On Mon, 19 May 2014 11:44:06 -0300, George Christman < > >> >> > gchrist...@cardaddy.com> wrote: > >> >> > > >> >> > In this particular case the application sits behind a firewall > with > >> no > >> >> >> public access so I don't believe this is bot activity. Do you > have > >> any > >> >> >> other thoughts? > >> >> >> > >> >> > > >> >> > Do you have any information on when this exception actually > happens? > >> >> > Otherwise, we can only guess. That exception usually happens when a > >> >> > Tapestry form URL is requested without the form fields, hence the > bot > >> >> > suspicion. > >> >> > > >> >> > > >> >> > -- > >> >> > Thiago H. de Paula Figueiredo > >> >> > Tapestry, Java and Hibernate consultant and developer > >> >> > http://machina.com.br > >> >> > > >> >> > > - > >> >> > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > >> >> > For additional commands, e-mail: users-h...@tapestry.apache.org > >> >> > > >> >> > > >> >> > >> >> > >> >> -- > >> >> George Christman > >> >> www.CarDaddy.com > >> >> P.O. Box 735 > >> >> Johnstown, New York > >> >> > >> > >> - > >> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > >> For additional commands, e-mail: users-h...@tapestry.apache.org > >> > >> > > > > > > -- > > George Christman > > www.CarDaddy.com > > P.O. Box 735 > > Johnstown, New York > > > > > > > -- > George Christman > www.CarDaddy.com > P.O. Box 735 > Johnstown, New York > -- Dmitry Gusev AnjLab Team http://anjlab.com
Re: Forms require that the request method be POST
So I finally figured out how to reproduce this exception. I'm using Tapestry-Security and if the session times out and the user submits the form, the page is redirected to the login page. When the user logs in, it attempts to resubmit the form and ends with this exception. Does anybody know how to handle this? On Mon, May 19, 2014 at 10:53 PM, George Christman wrote: > Thanks for the tips guys, I'll see if I can find the culprit now that I > know why it's happening. > > > On Mon, May 19, 2014 at 5:52 PM, Eugen wrote: > >> Hi, I have had this kind of exception then i tried to submit a form >> programmatically from an Applet (HttpClient) without sending the >> formData field. >> >> 2014-05-19 22:31 GMT+02:00 Kristian Marinkovic < >> kristian.marinko...@gmail.com>: >> > Hi, >> > >> > check if it is the same client. i once had the same problem. After >> several >> > hours of investigation it was a developer with a browser plugin (web >> > developer) which enabled converting form post requests to get requests. >> > >> > hope this helps. >> > >> > g, >> > Kris >> > >> > >> > On Mon, May 19, 2014 at 5:55 PM, George Christman >> > wrote: >> > >> >> Let me do some more homework now that I at least now how it's thrown. >> >> Thanks Thiago. >> >> >> >> >> >> On Mon, May 19, 2014 at 10:54 AM, Thiago H de Paula Figueiredo < >> >> thiag...@gmail.com> wrote: >> >> >> >> > On Mon, 19 May 2014 11:44:06 -0300, George Christman < >> >> > gchrist...@cardaddy.com> wrote: >> >> > >> >> > In this particular case the application sits behind a firewall with >> no >> >> >> public access so I don't believe this is bot activity. Do you have >> any >> >> >> other thoughts? >> >> >> >> >> > >> >> > Do you have any information on when this exception actually happens? >> >> > Otherwise, we can only guess. That exception usually happens when a >> >> > Tapestry form URL is requested without the form fields, hence the bot >> >> > suspicion. >> >> > >> >> > >> >> > -- >> >> > Thiago H. de Paula Figueiredo >> >> > Tapestry, Java and Hibernate consultant and developer >> >> > http://machina.com.br >> >> > >> >> > - >> >> > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org >> >> > For additional commands, e-mail: users-h...@tapestry.apache.org >> >> > >> >> > >> >> >> >> >> >> -- >> >> George Christman >> >> www.CarDaddy.com >> >> P.O. Box 735 >> >> Johnstown, New York >> >> >> >> - >> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org >> For additional commands, e-mail: users-h...@tapestry.apache.org >> >> > > > -- > George Christman > www.CarDaddy.com > P.O. Box 735 > Johnstown, New York > > -- George Christman www.CarDaddy.com P.O. Box 735 Johnstown, New York
Re: Forms require that the request method be POST
Thanks for the tips guys, I'll see if I can find the culprit now that I know why it's happening. On Mon, May 19, 2014 at 5:52 PM, Eugen wrote: > Hi, I have had this kind of exception then i tried to submit a form > programmatically from an Applet (HttpClient) without sending the > formData field. > > 2014-05-19 22:31 GMT+02:00 Kristian Marinkovic < > kristian.marinko...@gmail.com>: > > Hi, > > > > check if it is the same client. i once had the same problem. After > several > > hours of investigation it was a developer with a browser plugin (web > > developer) which enabled converting form post requests to get requests. > > > > hope this helps. > > > > g, > > Kris > > > > > > On Mon, May 19, 2014 at 5:55 PM, George Christman > > wrote: > > > >> Let me do some more homework now that I at least now how it's thrown. > >> Thanks Thiago. > >> > >> > >> On Mon, May 19, 2014 at 10:54 AM, Thiago H de Paula Figueiredo < > >> thiag...@gmail.com> wrote: > >> > >> > On Mon, 19 May 2014 11:44:06 -0300, George Christman < > >> > gchrist...@cardaddy.com> wrote: > >> > > >> > In this particular case the application sits behind a firewall with > no > >> >> public access so I don't believe this is bot activity. Do you have > any > >> >> other thoughts? > >> >> > >> > > >> > Do you have any information on when this exception actually happens? > >> > Otherwise, we can only guess. That exception usually happens when a > >> > Tapestry form URL is requested without the form fields, hence the bot > >> > suspicion. > >> > > >> > > >> > -- > >> > Thiago H. de Paula Figueiredo > >> > Tapestry, Java and Hibernate consultant and developer > >> > http://machina.com.br > >> > > >> > - > >> > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > >> > For additional commands, e-mail: users-h...@tapestry.apache.org > >> > > >> > > >> > >> > >> -- > >> George Christman > >> www.CarDaddy.com > >> P.O. Box 735 > >> Johnstown, New York > >> > > - > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > For additional commands, e-mail: users-h...@tapestry.apache.org > > -- George Christman www.CarDaddy.com P.O. Box 735 Johnstown, New York
Re: Forms require that the request method be POST
Hi, I have had this kind of exception then i tried to submit a form programmatically from an Applet (HttpClient) without sending the formData field. 2014-05-19 22:31 GMT+02:00 Kristian Marinkovic : > Hi, > > check if it is the same client. i once had the same problem. After several > hours of investigation it was a developer with a browser plugin (web > developer) which enabled converting form post requests to get requests. > > hope this helps. > > g, > Kris > > > On Mon, May 19, 2014 at 5:55 PM, George Christman > wrote: > >> Let me do some more homework now that I at least now how it's thrown. >> Thanks Thiago. >> >> >> On Mon, May 19, 2014 at 10:54 AM, Thiago H de Paula Figueiredo < >> thiag...@gmail.com> wrote: >> >> > On Mon, 19 May 2014 11:44:06 -0300, George Christman < >> > gchrist...@cardaddy.com> wrote: >> > >> > In this particular case the application sits behind a firewall with no >> >> public access so I don't believe this is bot activity. Do you have any >> >> other thoughts? >> >> >> > >> > Do you have any information on when this exception actually happens? >> > Otherwise, we can only guess. That exception usually happens when a >> > Tapestry form URL is requested without the form fields, hence the bot >> > suspicion. >> > >> > >> > -- >> > Thiago H. de Paula Figueiredo >> > Tapestry, Java and Hibernate consultant and developer >> > http://machina.com.br >> > >> > - >> > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org >> > For additional commands, e-mail: users-h...@tapestry.apache.org >> > >> > >> >> >> -- >> George Christman >> www.CarDaddy.com >> P.O. Box 735 >> Johnstown, New York >> - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Forms require that the request method be POST
Hi, check if it is the same client. i once had the same problem. After several hours of investigation it was a developer with a browser plugin (web developer) which enabled converting form post requests to get requests. hope this helps. g, Kris On Mon, May 19, 2014 at 5:55 PM, George Christman wrote: > Let me do some more homework now that I at least now how it's thrown. > Thanks Thiago. > > > On Mon, May 19, 2014 at 10:54 AM, Thiago H de Paula Figueiredo < > thiag...@gmail.com> wrote: > > > On Mon, 19 May 2014 11:44:06 -0300, George Christman < > > gchrist...@cardaddy.com> wrote: > > > > In this particular case the application sits behind a firewall with no > >> public access so I don't believe this is bot activity. Do you have any > >> other thoughts? > >> > > > > Do you have any information on when this exception actually happens? > > Otherwise, we can only guess. That exception usually happens when a > > Tapestry form URL is requested without the form fields, hence the bot > > suspicion. > > > > > > -- > > Thiago H. de Paula Figueiredo > > Tapestry, Java and Hibernate consultant and developer > > http://machina.com.br > > > > - > > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > > For additional commands, e-mail: users-h...@tapestry.apache.org > > > > > > > -- > George Christman > www.CarDaddy.com > P.O. Box 735 > Johnstown, New York >
Re: Forms require that the request method be POST
Let me do some more homework now that I at least now how it's thrown. Thanks Thiago. On Mon, May 19, 2014 at 10:54 AM, Thiago H de Paula Figueiredo < thiag...@gmail.com> wrote: > On Mon, 19 May 2014 11:44:06 -0300, George Christman < > gchrist...@cardaddy.com> wrote: > > In this particular case the application sits behind a firewall with no >> public access so I don't believe this is bot activity. Do you have any >> other thoughts? >> > > Do you have any information on when this exception actually happens? > Otherwise, we can only guess. That exception usually happens when a > Tapestry form URL is requested without the form fields, hence the bot > suspicion. > > > -- > Thiago H. de Paula Figueiredo > Tapestry, Java and Hibernate consultant and developer > http://machina.com.br > > - > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > For additional commands, e-mail: users-h...@tapestry.apache.org > > -- George Christman www.CarDaddy.com P.O. Box 735 Johnstown, New York
Re: Forms require that the request method be POST
On Mon, 19 May 2014 11:44:06 -0300, George Christman wrote: In this particular case the application sits behind a firewall with no public access so I don't believe this is bot activity. Do you have any other thoughts? Do you have any information on when this exception actually happens? Otherwise, we can only guess. That exception usually happens when a Tapestry form URL is requested without the form fields, hence the bot suspicion. -- Thiago H. de Paula Figueiredo Tapestry, Java and Hibernate consultant and developer http://machina.com.br - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Forms require that the request method be POST
In this particular case the application sits behind a firewall with no public access so I don't believe this is bot activity. Do you have any other thoughts? On May 19, 2014 10:00 AM, "Thiago H de Paula Figueiredo" wrote: > On Mon, 19 May 2014 09:37:44 -0300, George Christman < > gchrist...@cardaddy.com> wrote: > > Hi Everyone, I'm using 5.4 and I've continued to randomly see this >> exception popup in multiple applications. I'm wondering what it means and >> how to fix it. Thanks. >> > > Very probably bots crawling your site. > > -- > Thiago H. de Paula Figueiredo > Tapestry, Java and Hibernate consultant and developer > http://machina.com.br > > - > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > For additional commands, e-mail: users-h...@tapestry.apache.org > >
Re: Forms require that the request method be POST
On Mon, 19 May 2014 09:37:44 -0300, George Christman wrote: Hi Everyone, I'm using 5.4 and I've continued to randomly see this exception popup in multiple applications. I'm wondering what it means and how to fix it. Thanks. Very probably bots crawling your site. -- Thiago H. de Paula Figueiredo Tapestry, Java and Hibernate consultant and developer http://machina.com.br - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Forms require that the request method be POST
Hi Everyone, I'm using 5.4 and I've continued to randomly see this exception popup in multiple applications. I'm wondering what it means and how to fix it. Thanks. Forms require that the request method be POST and that the t:formdata query parameter have values.org.apache.tapestry5.ioc.internal.OperationException: Forms require that the request method be POST and that the t:formdata query parameter have values. [at classpath:org/healthresearch/eprs/pages/Purchase_Request.tml, line 2] at org.apache.tapestry5.ioc.internal.OperationTrackerImpl.logAndRethrow(OperationTrackerImpl.java:121) at org.apache.tapestry5.ioc.internal.OperationTrackerImpl.invoke(OperationTrackerImpl.java:88) at org.apache.tapestry5.ioc.internal.PerThreadOperationTracker.invoke(PerThreadOperationTracker.java:87) at org.apache.tapestry5.ioc.internal.RegistryImpl.invoke(RegistryImpl.java:1124) at org.apache.tapestry5.internal.structure.ComponentPageElementResourcesImpl.invoke(ComponentPageElementResourcesImpl.java:146) at org.apache.tapestry5.internal.structure.ComponentPageElementImpl.triggerContextEvent(ComponentPageElementImpl.java:1058) at org.apache.tapestry5.internal.services.ComponentEventRequestHandlerImpl.handle(ComponentEventRequestHandlerImpl.java:81) at org.apache.tapestry5.internal.services.ImmediateActionRenderResponseFilter.handle(ImmediateActionRenderResponseFilter.java:42) at $ComponentEventRequestHandler_16eae9ba3622.handle(Unknown Source) at org.apache.tapestry5.internal.services.AjaxFilter.handle(AjaxFilter.java:42) at $ComponentEventRequestHandler_16eae9ba3622.handle(Unknown Source) at org.apache.tapestry5.upload.internal.services.UploadExceptionFilter.handle(UploadExceptionFilter.java:75) at $ComponentEventRequestHandler_16eae9ba3622.handle(Unknown Source) at org.apache.tapestry5.services.TapestryModule$41.handle(TapestryModule.java:2476) at $ComponentEventRequestHandler_16eae9ba3622.handle(Unknown Source) at $ComponentEventRequestHandler_16eae9ba3588.handle(Unknown Source) at org.apache.tapestry5.internal.services.ComponentRequestHandlerTerminator.handleComponentEvent(ComponentRequestHandlerTerminator.java:43) at org.apache.tapestry5.services.InitializeActivePageName.handleComponentEvent(InitializeActivePageName.java:39) at $ComponentRequestHandler_16eae9ba358a.handleComponentEvent(Unknown Source) at org.tynamo.security.SecurityComponentRequestFilter.handleComponentEvent(SecurityComponentRequestFilter.java:42) at $ComponentRequestFilter_16eae9ba3587.handleComponentEvent(Unknown Source) at $ComponentRequestHandler_16eae9ba358a.handleComponentEvent(Unknown Source) at $ComponentRequestHandler_16eae9ba3558.handleComponentEvent(Unknown Source) at org.apache.tapestry5.internal.services.ComponentEventDispatcher.dispatch(ComponentEventDispatcher.java:46) at $Dispatcher_16eae9ba355b.dispatch(Unknown Source) at $Dispatcher_16eae9ba3554.dispatch(Unknown Source) at org.apache.tapestry5.services.TapestryModule$RequestHandlerTerminator.service(TapestryModule.java:302) at org.apache.tapestry5.internal.services.RequestErrorFilter.service(RequestErrorFilter.java:26) at $RequestHandler_16eae9ba3555.service(Unknown Source) at org.apache.tapestry5.services.TapestryModule$3.service(TapestryModule.java:902) at $RequestHandler_16eae9ba3555.service(Unknown Source) at org.apache.tapestry5.services.TapestryModule$2.service(TapestryModule.java:892) at $RequestHandler_16eae9ba3555.service(Unknown Source) at org.apache.tapestry5.internal.services.StaticFilesFilter.service(StaticFilesFilter.java:90) at $RequestHandler_16eae9ba3555.service(Unknown Source) at $RequestHandler_16eae9ba354b.service(Unknown Source) at org.apache.tapestry5.services.TapestryModule$HttpServletRequestHandlerTerminator.service(TapestryModule.java:253) at org.apache.tapestry5.upload.internal.services.MultipartServletRequestFilter.service(MultipartServletRequestFilter.java:44) at $HttpServletRequestHandler_16eae9ba354d.service(Unknown Source) at org.got5.tapestry5.jquery.services.AjaxUploadServletRequestFilter.service(AjaxUploadServletRequestFilter.java:27) at $HttpServletRequestHandler_16eae9ba354d.service(Unknown Source) at org.apache.tapestry5.internal.services.IgnoredPathsFilter.service(IgnoredPathsFilter.java:62) at $HttpServletRequestFilter_16eae9ba3547.service(Unknown Source) at $HttpServletRequestHandler_16eae9ba354d.service(Unknown Source) at org.tynamo.security.filter.SecurityRequestFilter$3.doFilter(SecurityRequestFilter.java:179) at org.apache.shiro.web.servlet.AbstractShiroFilter.executeChain(AbstractShiroFilter.java:359) at org.apache.shiro.web.servlet.AbstractShiroFilter$1.call(AbstractShiroFilter.java:275) at org.apache.shiro.subject.support.SubjectCallable.doCall(SubjectCallable.java:90) at org.apache.shiro.subject.support.SubjectCallable.call(SubjectCallable.java:83) at org.apache.shiro.subject.support.DelegatingSubject.execute(DelegatingSubject.java:344) at org.apache.shiro.web.servlet.AbstractShiroFilter.doFilterInternal(AbstractShiroFilt
Re: Forms require that the request method be POST and that the t:formdata query parameter have values.
I'm sure there are GET requests from search bots. Make sure you exclude action/event links and form actions in robots.txt (like Disallow: /*?t:ac=*, Disallow: */pagename.component:action* 02.12.2013 17:41, Ben Titmarsh пишет: Hi Guys, I'm getting quite a lot of these exceptions in my logs. I've read all of the posts on the mailing list and it seems like the only accepted solution is to use request filtering to check for an exception with a message containing "Forms require that the request method be POST" and do a redirect. Is this still our best option? Secondly is this problem really only occurring due to browsers saving URLs to form submissions in their smart bars? My site gets around 15k page views a day and in the last 24 hours I've had 284 of these. Maybe that's about right, it just seems high to me! Cheers, Ben. - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Forms require that the request method be POST and that the t:formdata query parameter have values.
Hi Guys, I'm getting quite a lot of these exceptions in my logs. I've read all of the posts on the mailing list and it seems like the only accepted solution is to use request filtering to check for an exception with a message containing "Forms require that the request method be POST" and do a redirect. Is this still our best option? Secondly is this problem really only occurring due to browsers saving URLs to form submissions in their smart bars? My site gets around 15k page views a day and in the last 24 hours I've had 284 of these. Maybe that's about right, it just seems high to me! Cheers, Ben.
IGNORE: odd exception on deployed app: Forms require that the request method be POST and that the t:formdata query parameter have values.
please ignore this subject
odd exception on deployed app: Forms require that the request method be POST and that the t:formdata query parameter have values.
Hi,
This template worked fine before I tweaked my log4j and one of my service
classes, now it crashes. What is it talking about, page works fine on dev
system?
John
An unexpected application exception has occurred.
a.. org.apache.tapestry5.ioc.internal.OperationException
Forms require that the request method be POST and that the t:formdata query
parameter have values.
location
classpath:com/quivinco/webapps/tbs/pages/vendor/Signup.tml, line 83
xmlns:p="tapestry:parameter">
4
5 ${message:text.para1}
6 ${message:text.para2}
7
8
9
10
11
12 ${message:label.username}
13 http://java.oracle.com/
java.vendor.url.bug
http://bugreport.sun.com/bugreport/
java.version
1.7.0_21
java.vm.info
mixed mode
java.vm.name
Java HotSpot(TM) Client VM
java.vm.specification.name
Java Virtual Machine Specification
java.vm.specification.vendor
Oracle Corporation
java.vm.specification.version
1.7
java.vm.vendor
Oracle Corporation
java.vm.version
23.21-b01
line.separator
maven.home
/usr/share/maven
os.arch
i386
os.name
Linux
os.version
3.0.20-xenU
path.separator
:
securerandom.source
file:/dev/./urandom
sun.arch.data.model
32
sun.boot.class.path
a.. /usr/java/jdk1.7.0_21/jre/lib/resources.jar
b.. /usr/java/jdk1.7.0_21/jre/lib/rt.jar
c.. /usr/java/jdk1.7.0_21/jre/lib/sunrsasign.jar
d.. /usr/java/jdk1.7.0_21/jre/lib/jsse.jar
e.. /usr/java/jdk1.7.0_21/jre/lib/jce.jar
f.. /usr/java/jdk1.7.0_21/jre/lib/charsets.jar
g.. /usr/java/jdk1.7.0_21/jre/lib/jfr.jar
h.. /usr/java/jdk1.7.0_21/jre/classes
sun.boot.library.path
/usr/java/jdk1.7.0_21/jre/lib/i386
sun.cpu.endian
little
sun.cpu.isalist
sun.io.unicode.encoding
UnicodeLittle
sun.java.command
org.codehaus.plexus.classworlds.launcher.Launcher jetty:run
sun.java.launcher
SUN_STANDARD
sun.jnu.encoding
ANSI_X3.4-1968
sun.management.compiler
HotSpot Client Compiler
sun.os.patch.level
unknown
tapestry.execution-mode
development
user.country
US
user.dir
/usr/java/app
user.home
/root
user.language
en
user.name
root
user.timezone
Etc/UTC
Re: Forms require that the request method be POST and that the t:formdata query parameter have values
See http://tapestry.1045711.n5.nabble.com/Safari-for-example-browser-history-and-form-exception-td4942074.html On 08/12/2012, at 10:09 PM, Muhammad Gelbana wrote: > I think this error occurs when you visit a similar url (through a GET > request, just by putting the following address in the browser's address bar > and hitting enter): > > http://localhost/pagename.formid > > This url is the "action" attribute value for the form element. It should be > using within an http POST request, not a GET request. > > Or may be your form's "method" attribute value is "get" ?! > > On Sat, Dec 8, 2012 at 4:02 AM, TG wrote: > >> In 5.3.6, I got this error if I use a form based submission. How do I avoid >> this? There was no such error prior to 5.3.6. >> >> Thanks. >> >> >> >> -- >> View this message in context: >> http://tapestry.1045711.n5.nabble.com/Forms-require-that-the-request-method-be-POST-and-that-the-t-formdata-query-parameter-have-values-tp5718554.html >> Sent from the Tapestry - User mailing list archive at Nabble.com. >> >> - >> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org >> For additional commands, e-mail: users-h...@tapestry.apache.org >> >> - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Forms require that the request method be POST and that the t:formdata query parameter have values
I think this error occurs when you visit a similar url (through a GET request, just by putting the following address in the browser's address bar and hitting enter): http://localhost/pagename.formid This url is the "action" attribute value for the form element. It should be using within an http POST request, not a GET request. Or may be your form's "method" attribute value is "get" ?! On Sat, Dec 8, 2012 at 4:02 AM, TG wrote: > In 5.3.6, I got this error if I use a form based submission. How do I avoid > this? There was no such error prior to 5.3.6. > > Thanks. > > > > -- > View this message in context: > http://tapestry.1045711.n5.nabble.com/Forms-require-that-the-request-method-be-POST-and-that-the-t-formdata-query-parameter-have-values-tp5718554.html > Sent from the Tapestry - User mailing list archive at Nabble.com. > > - > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > For additional commands, e-mail: users-h...@tapestry.apache.org > >
Forms require that the request method be POST and that the t:formdata query parameter have values
In 5.3.6, I got this error if I use a form based submission. How do I avoid this? There was no such error prior to 5.3.6. Thanks. -- View this message in context: http://tapestry.1045711.n5.nabble.com/Forms-require-that-the-request-method-be-POST-and-that-the-t-formdata-query-parameter-have-values-tp5718554.html Sent from the Tapestry - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Forms require that the request method be POST....
Ok, I will try it in my code. Thanks Lenny! -- David Germán Canteros 2012/3/20 Lenny Primak > I am the author of that fix and it definitely works correctly. > It strips out the form from the request and redirects it to the page that > the > client was actually looking for. > > On Mar 20, 2012, at 9:04 AM, David Canteros wrote: > > > Hi guys! > > Lately I detected a lot of this exception in the logs of my tap > > applications... It said: > > > > *org.apache.tapestry5.ioc.internal.OperationException: Forms require that > > the request method be POST and that the t:formdata query parameter have > > values. [at context:courses/ManageCoursesPage.tml, line 8]* > > > > The .tml > > > >... > > > > > > This happens often, but not all the time... I didn't found external > causes, > > so i believe that are related with tapestry... I was looking for fix in > the > > mailing list, but only found some tricks... > > For example > > > http://tapestry.1045711.n5.nabble.com/Safari-for-example-browser-history-and-form-exception-td4942074.html > , > > > > In this case, it decorates the RequestExceptionHandler and checks if the > > exception contains the string "*Forms require that the request..*.", if > > true then throws some kind on redirect... Can anybody say if this fix is > > correct?? Otherwise, can anybody suggest other more clear fix, or provide > > some context to understand the exception? > > > > Thanks in advance! > > David > > > > > > -- > > David Germán Canteros > > > - > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > For additional commands, e-mail: users-h...@tapestry.apache.org > >
Re: Forms require that the request method be POST....
I am the author of that fix and it definitely works correctly. It strips out the form from the request and redirects it to the page that the client was actually looking for. On Mar 20, 2012, at 9:04 AM, David Canteros wrote: > Hi guys! > Lately I detected a lot of this exception in the logs of my tap > applications... It said: > > *org.apache.tapestry5.ioc.internal.OperationException: Forms require that > the request method be POST and that the t:formdata query parameter have > values. [at context:courses/ManageCoursesPage.tml, line 8]* > > The .tml > >... > > > This happens often, but not all the time... I didn't found external causes, > so i believe that are related with tapestry... I was looking for fix in the > mailing list, but only found some tricks... > For example > http://tapestry.1045711.n5.nabble.com/Safari-for-example-browser-history-and-form-exception-td4942074.html, > > In this case, it decorates the RequestExceptionHandler and checks if the > exception contains the string "*Forms require that the request..*.", if > true then throws some kind on redirect... Can anybody say if this fix is > correct?? Otherwise, can anybody suggest other more clear fix, or provide > some context to understand the exception? > > Thanks in advance! > David > > > -- > David Germán Canteros - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
Re: Forms require that the request method be POST....
I forgot to say that I'm using tapestry 5.3.2 running on tomcat 6, and the exceptions happens which users who use Firefox 3... -- David Germán Canteros 2012/3/20 David Canteros > Hi guys! > Lately I detected a lot of this exception in the logs of my tap > applications... It said: > > *org.apache.tapestry5.ioc.internal.OperationException: Forms require that > the request method be POST and that the t:formdata query parameter have > values. [at context:courses/ManageCoursesPage.tml, line 8]* > > The .tml > > ... > > > This happens often, but not all the time... I didn't found external > causes, so i believe that are related with tapestry... I was looking for > fix in the mailing list, but only found some tricks... > For example > http://tapestry.1045711.n5.nabble.com/Safari-for-example-browser-history-and-form-exception-td4942074.html, > > In this case, it decorates the RequestExceptionHandler and checks if the > exception contains the string "*Forms require that the request..*.", if > true then throws some kind on redirect... Can anybody say if this fix is > correct?? Otherwise, can anybody suggest other more clear fix, or provide > some context to understand the exception? > > Thanks in advance! > David > > > -- > David Germán Canteros >
