I have a ColdFusion enabled form (for validation) submitting to a separate page. When this form is submitted it is showing me a 404 on the action page, yet when I directly load the action url into the address bar it shows up (errors appear, but that's ok). This is by far one of the most odd issues I have encountered.
Form page: http://www.jefferson.edu/population_health/_archive/contact_me.cfm
Action page: http://www.jefferson.edu/population_health/_archive/contact_action.cfm
Even if I try passing the form variables via URL it gives me a 404.
My gut is that there is another service on that machine that is trying to take over the request whenever you submit data and binding it to another webserver...which, of course, it can't find the right page based on it's own webroot.
If you click http://www.jefferson.edu/population_health/_archive/contact_me.cfm, it loads fine and returns 200 header with IIS as the server, but if you click http://www.jefferson.edu/population_health/_archive/contact_me2.cfm it throws a 404, as expected, but it's properly handled with a custom 404 and the header response is still IIS. But if you click http://www.jefferson.edu/population_health/_archive/contact_me.cfm?foo=bar, it returns an ApacheSling default 404 and header information saying the server is "Day-Servlet-Engine/4.1.12".
Your page is posting to the page contact_action.cfm ... in your question you indicate that the proper page should be "mailaction.cfm".
If the action page is actually mailaction.cfm then you simply need to change the action attribute of your cfform.
Related
Currently it is only possible to add one error handler per HTTP status code in the site configuration, e.g. for 404 or 403. Alternatively you can always write your custom error handler. But this makes it a bit inflexible.
Imagine the following scenario:
default 404 handling would be a specific page, e.g. 12
in a custom error handler I have a cache of URI-to-page mapping. If this gets a hit, the page from that should be displayed. If not, the generic error page 12
which page is displayed should be configurable in the site configuration
or
for 403 I have an error handler which can redirect to a login page
however this may not work in some cases where it should default to standard 403 page
Nice would be if you could configure this for the site so you have something like this:
404
| - custom error handler 1
| - custom error handler 2
| - page error handler
Keeping your extension with the custom error handlers, you could just replace the "page error handler" with a Fluid template for the last step via site configuration.
However, the site module only allows for one error handler per status code (e.g. 404).
I am thinking it might be useful to change this in the TYPO3 core.
But would like to know how others would solve this first.
I'm using FlowRouter. If I start on the homepage everything works well. I can work through the routes (change the pages) without problem. However, if I hit refresh in the browser, I get a series of errors. My url looks like this:
/story/586d536e34821281735b53a4
The ID is being returned in console under the following method:
Tracker.nonreactive(function(){
I think the subscription is being completed, so I'm a little confused as to why reloading a url is different than loading from the home page.
What am I not understanding here?
Reloading a url will make a HTTP request to server to get all the application source. Whereas navigating to a route from another one does not make any HTTP requests to get the application source because they are already available (they were loaded from the previous route), in this case the router will just get the appropriate content and render on the page. This is normal behaviour for Meteor apps and all other single-page apps
The error you encounter is because your data is not yet available on client, to fix it you could simple use a placeholder if the value is undefined.
This question already has answers here:
Prevent user from seeing previously visited secured page after logout
(7 answers)
Closed 6 years ago.
I have a JSP page with a form where you fill up certain details. On submitting the form i call a servlet which then updates details in a database after that i redirect to a page i display a confirmation message to the user.
The problem i have here is when the user clicks back he goes to the form page again where if he clicks a submit button, it creates a new record in the database.
Consider this similar to a shopping cart example where in this case he would buy the same item twice. But the only problem here is i cannot handle this in backend, i.e. the database can never know a redundant operation is taking place.
I need to handle this from the client side.Bit weird but i have to do it this way.
Basically when the user clicks the back button i don't want him to be able to go to the form page and may be just to some other page.
This is a typical HTML form issue, you can solve it through any one of following methods
1) Server side (page expiration): Since you've mentioned that the page refreshes and goes to the confirmation. You can set no-cache and add a page expiration time as -1 to the page you have that form.
So that when user presses the back button, he will see that the page has expired. He will be forced to load the page freshly. This is the behavior that I see in most banking websites.
Response.Buffer = True
Response.ExpiresAbsolute = Now() - 1
Response.Expires = 0
Response.CacheControl = "no-cache"
2) Using turn Key method: When the form loads, you can generate a random key in session memory and also embed it as a hidden value in the page.
During form submission, check the submitted hidden key against the value in session. If exists, then add the entry to database otherwise you can reload the page with a fresh key for the user (who might have done that unintentionally).
In load balanced or web farms, consider persisting the turn key in Database against the current user.
3) Client Side (Not recommended) : You can restrict the user from using the browser back button by removing the page from the history. (One side effect is that it will remove the entire history for that browser tab/window)
history.pushState(null, null, document.title);
window.addEventListener('popstate', function () {
history.pushState(null, null, document.title);
});
If you need the same support for older browsers where push and pop states are not supported, you can use following snippet.
<script>
function preventBack() {
window.history.forward();
}
setTimeout("preventBack()", 0);
window.onunload = function() {
null
};
</script>
Before redirecting to the JSP page send these headers with the response from the controller so that the page is not stored in cache and the browser will always request a new page from the server.
response.setHeader("Cache-Control", "no-cache, no-store, must-revalidate"); // HTTP 1.1.
response.setHeader("Pragma", "no-cache"); // HTTP 1.0.
response.setDateHeader("Expires", 0);
So every time you go back to that page a new page will be requested from the server and will be displayed with the cleared input fields.
You could implement a PRG-Pattern (https://en.wikipedia.org/wiki/Post/Redirect/Get) using php.
Basically, after successfully submitting the form you redirect to a confirmation page which informs the user that their submission was successful/accepted/etc. and also set a variable which you can later use to check if said submission has been submitted yet.
When the user tries to reload said page or go back you can check the variable and display either the form again or the confirmation page based on if the submission has been submitted already.
I think following flow is the best:
Client submits data to server
Servlet processes it
It returns HTTP 303 redirect to client
Client redirects to success page
After this flow, refresh, back button will work properly.
For more information read Simple Post-Redirect-Get code example
The question is generally language/framework agnostic but if it matters I work with Grails and most interested in grails specific solution if such exists.
There's a form mapped to URL: /foo/create. When user type in this URL to his browser the form is shown.
Form action attribute directs to /foo/save and has method POST. If saving is successful, then standard post-redirect-get pattern is applied, and user is redirected to /foo/show.
But, if user specified incorrect data, they should see the same form again with error messages and all their data preserved. To implement this behavior, I do forward to the controller which produces the form (the same is mapped to /foo/create).
After that user sees the form with data and error messages, but URL field is changed in browser to /foo/save. And if user change focus to URL field and press enter - 404 will be shown (because nothing is mapped to /foo/save + method=GET pair).
The long story short: URL /foo/save is shown in a browser (as there were no redirection after form was submitted) but it directs to nowhere if accessed by HTTP GET method.
How to deal with this situation? Surely, I can map something to /foo/save but I wonder if there's a way not to change URL shown in a browser after form with wrong data was submitted?
Two approaches:
The form submits to itself, i.e. /foo/create submits to /foo/create, only if successful the page is redirected to /foo/show. This should use a post-redirect-get cycle as well and store the submitted data in the session, but could be a simple POST without redirect.
/foo/save always redirects again, either to /foo/create if the data was invalid or to /foo/show if the data was valid. This will always use a post-redirect-get cycle with the data saved in the session.
In Drupal 7, some of (non-existing) URLs are not redirecting to 404 or any error page it should. Instead, it still remains showing its Top Parent Folder. For example like:
www.mywebsite.com/items/aaaaaaaaaaaaa
www.mywebsite.com/items/bbbbbbbbbbbbbbbbbb
Every WRONG URLs under /items/ i put like above, are showing the Page of its parent:
www.mywebsite.com/items instead of get redirected to 404
I don't want its parent to be shown if there is no page really.
But the strange thing is, it is NOT happening on every patterns. I mean, another different parents like:
www.mywebsite.com/users/aaaaaaaaaaaaa
www.mywebsite.com/users/bbbbbbbbbbbbbbbbb
For the wrong url typed-in under this /users/ parent path, it is CORRECTLY redirecting to the 404 page.
What is it please?
If I understand your question correctly, it's not a problem at all.
That's because how your/contributed/core modules hooks Drupal menu system.
If a menu item (menu router item to be specific. Think about a path like "admin/config/development/performance") has no "%" sign in it, menu callback function will be executed.
For an example, if a module registers "items" path example.com/items path would not be a 404, and the appropriate menu callback function of the menu item will be fired. That callback function can make use of further URL parts (example.com/items/123) if given.
'node' is a good example. (technically they are different menu router items though) .
Opening example.com/node will not fire a 404.
If a module registers 'items/%' , then, example.com/items will fire a 404. In other words, the second URL part is required in order to execute the menu callback function.
If the problem you are facing is related to a custom module, make sure you register the correct version of your router items. If the second URL part is required, register items/%.
You can execute a 404 by calling drupal_not_found().
Look at this, really helpfull
http://peterpetrik.com/blog/2009/11/non-existent-urls-views-2
Are you using Views for that path (/items)?
Here is an issue for Views: Prevent duplicate content (because Views returns 200 instead of 400 404)
You could create a Contextual filter to prevent this.
merlinofchaos wrote:
If you don't want this behavior, add the Global: NULL argument to Views and use the setting to validate that the argument is empty.
For Drupal 6, the module Views 404 might help.
You can configure your drupal installation to redirect to a specefic 404 page that you create..
Go to www.yoursite.com/admin/config/system/site-information and enter your 404 page .