On Tue, 2006-06-06 at 22:11 -0500, Adrian Holovaty wrote: > http://code.djangoproject.com/wiki/NewbieMistakes#POSTtoviewslosesPOSTdata > > It's about time to solve this one. Who has a creative, elegant solution? :-) > > Some ideas, just to start discussion -- > > * THROW ERROR ON POST: The CommonMiddleware, when adding a slash and > redirecting, can check for POST data. If it finds any, it somehow logs > the error or otherwise alerts the developer. Maybe if DEBUG=True it > can actually display an error, with a custom-built message saying "You > need to change so-and-so form action to so-and-so URL"? I can't think > of any case in which a POST to a page that needs to be redirected > would be intentional, and if we only do it for DEBUG=True I think this > may be acceptable.
I like this one. I would prefer to see the error is thrown whenever we are going to add a slash and the method is POST. Checking for POST data is probably over-specialising. The problem we are trying to solve is User Agents rewriting a POST as a GET, so if the original submission intended POST then -- whether or not there is data -- we should try to avoid the User Agents' bug in all circumstances. This really feels like a good solution. We are alerting the site developer to the problem as soon as we know about it and in a way that does not add a lot of extra processing time on the Django side. Also, what is the behaviour for other non-GET methods (DELETE, PUT)? Arguably, they are less vulnerable, since they will be sent by (more likely) non-browser clients and the coder should be able to read the spec, but should we be proactive and trigger the same error whenever the method is not GET? I would vote "yes" on this, but from a position of ignorance, I'll admit. > * THROW ERROR ON FORM DISPLAY: If the APPEND_SLASH setting is set to > True and the CommonMiddleware is activated, Django could check the > output of every page for a <form> whose method is POST and has an > "action" whose URL doesn't end in a slash. Then it could somehow alter > the page to display an error on it. This solution is horrific, but I'm > mentioning it here for diversity. Err ... no. :-( Could we not mention this one ever again? Please? Malcolm --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~----------~----~----~----~------~----~------~--~---
