Selenium (RC) is being used to test an ASP.NET 1.1 site.
When we make a request via Selenium RC (which in turn automates the request via a configured browser - in this case Firefox) the http verb is "HEAD". We have several form action methods that have separate GET and POST methods decorated with AcceptVerbs(HttpVerbs.Get) or HttpVerbs.Post respectively. These methods are returning a 404 and logging a "a public action method could not be found" error message.
Questions:
When writing separate Get/Post action methods what is the best practice for handling the Head verb? Should we always decorate with an AcceptVerbs(HttpVerbs.Get | HttpVerbs.Head)?
Why is the HEAD verb being generated when Selenium RC is automating the browser in lieu of an If-Modified-Since header?
We've also seen log entries from (non-mainstream) crawlers that are using the HEAD verb. We created robots.txt entries to stop these crawlers from indexing the site, but now we're wondering what the best practice from an SEO perspective is as well. Is it important to respond to HEAD for crawlers? Are there mainstream crawlers that use it? Does it impact SEO rank?
Yes, I think that whenever you are restricting your requests to be GET only, you should always allow HEAD on them as well - in fact, I do think it should be built into the MVC framework (next thing on my todo list: raise the issue in MVC bug tracker that [HttpGet] attribute should somehow support HEAD verb)
I would like to know an answer to this too. In the meantime, there is a suggested workaround - pass 'true' as a second param to Selenium's open().
I don't think it impacts SERP ranking per se, however I can see how crawlers would not request the full page if HEAD gives a 404. According to the HTTP spec (RFC2616), "The HEAD method is identical to GET except that the server MUST NOT return a message-body in the response", so, if you are doing things right - it shouldn't be a problem to allow the method and avoid getting unlisted.
Related
In my Zend Framework MVC application I am using only two request methods: GET and POST. I am wondering whether I should put a check in my base controller to throw an exception if the other request types are received (e.g. PUT or DELETE).
As far as I can see there are two areas for consideration:
Would it improve security at all? Am I giving potential hackers a head start if I allow the framework to respond to PUT, DELETE, et al?
Would it interfere with correct operation of the site? For example, do search engine bots rely on requests other than GET and POST?
Your ideas are much appreciated!
The correct response code would be 405 Method Not Allowed, including an Allow: GET, POST header.
10.4.6 405 Method Not Allowed
The method specified in the Request-Line is not allowed for the resource identified by the Request-URI. The response MUST include an Allow header containing a list of valid methods for the requested resource.
http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html
People violate the api of your app/framework/site etc either due to errors or on purpose, to probe your site for weaknesses. (Only matters in frequency if your site is internal only or on the public net.)
If your site supports developers, then that'd be a possible reason to reply with a 405 code of method not allowed. Perhaps only if the session (assuming sessions) is marked as being in developer mode.
If you don't expect valid developers, then I recommend silently swallowing any bad input to make it harder for the bad guys.
Another reason not to give error messages in the normal case: the lack of an error message in a particular case can then be interpreted that the bad data made it further into your stack than other data--outlining a possible attack route.
And finally, error returns (type, delay before responding, and more) can be used to characterize a particular version of an app/framework etc. This can then be used to quickly locate other vulnerable installations once an attack vector is found.
Yes, the above is pessimistic, and I fondly remember the 80's when everybody responded to ping, echo and other diagnostic requests. But the bad guys are here and it is our responsibility to harden our systems. See this TED video for more.
I am using Spring Mvc.Here I have used JSP as a view.
I have a situation,in which I have to redirect to another form which is subjected to another controller,from a form which is subjected to another controller
I have used
<c:redirect url="updateStock.ic?appId='${mineralSelect.applicationId}'&serviceId='${mineralSelect.serviceId}'&mineralIdAndName='${mineralList.get(0).mineralId}:${mineralList.get(0).mineralName}'"/>
But it is executed,but the page is not rendered.But in the console view there is no exception page.
Since I didn't get an answer to my comment, I will try to give you the best answer with limited knowledge that I possibly can.
First, I think it's bad practice to put redirects in your JSPs. Frankly, I think its bad practice to put anything other than simple loops and decision branches in your JSPs. I would consider the decision to do a redirect a "business logic" decision, and one I would not make in my JSP. Spring MVC provides several methods to do a redirect in the controller, which has the added benefit of not being in the JSP, and would bypass having to render the JSP to perform the redirect. This posting has some examples of how to perform a redirect in the controller.
If you still have your heart set on doing the redirect in your JSP, then I would suggest breaking out some testing tools to see if you are getting the redirect at all. Chrome's Developer Tools and Firefox's Firebug have the ability report what gets sent to your browser. Fiddler is also a good tool for these things. What you are looking for is an HTTP 3xx header, most likely a 302, with the URL that you are trying to redirect to.
If you are not seeing the HTTP 3xx response in the browser, then its time to troubleshoot. Start by asking the following:
Is the JSP ever rendering at all
If it is rendering, what happens if I put debug statements around my redirect?
Is there some logic around my redirect that is causing it to not even get executed (debug statements might elude to this)
Start as close to the source as possible, adding debug prints and logging, then expand out to the next widest area until you determine what is working and what is not working.
I am trying to work out how to access content on this site: https://handbook.unimelb.edu.au/
I can manually conduct a search via the browser, and I am tracking the raw http request via HTTP live Headers, but having endless problems working out how the system is actually conducting search.
In particular, using the advanced search via: https://handbook.unimelb.edu.au/faces/htdocs/user/search/AdvancedSearch.jsp
Results in data similar to the following being sent:
POST /faces/htdocs/user/search/AdvancedSearch.jsp HTTP/1.1
AdvancedSearchForm%3Akeywords=&AdvancedSearchForm%3ACourseOrSubjectSelection=SUBJECT_ALL&AdvancedSearchForm%3AGraduateLevelSelection=POSTGRADUATE_ALL&AdvancedSearchForm%3AfacultyList=&AdvancedSearchForm%3AdepartmentList=&AdvancedSearchForm%3Alevel=ALL&AdvancedSearchForm%3Asemester=ALL&AdvancedSearchForm%3AallStudyAreas=t&oracle.adf.faces.FORM=AdvancedSearchForm&oracle.adf.faces.STATE_TOKEN=_id51018%3A_id51019&source=AdvancedSearchForm%3AsearchButton
The server immediately responds with "HTTP/1.1 302 Moved Temporarily" and redirects me to "Location: https://handbook.unimelb.edu.au/faces/htdocs/user/search/SearchResults.jsp"
Which actually displays the search results.
As far as I can tell, the search itself must be using a session to store the searched-for terms between the post and the subsequent get.
Is this normal JSF behaviour?
Is there a trick to accessing such a system?
Is this normal JSF behaviour?
This bahaviour is not "normal". This approach is however explainable for legacy JSF 1.x applications; it's because GET forms weren't natively supported by JSF 1.x. I would however consider this approach rather poor design and have recommended to use <managed-property> to inject GET request parameters. The webapp architect/developer has most likely not really thought it out very well. Note that since JSF 2.0, which is out for little over 3 years already, GET forms using plain HTML <form> are natively supported thanks to the new <f:viewParam> tag.
Is there a trick to accessing such a system?
Tell your HTTP client to maintain the session (read: the cookies) and auto-follow redirects. By default, JSF relies heavily on the session already as it stores the view state in there as well. This is in turn not related to the way how that webapp is designed.
See also:
How can i programmatically upload a file to a website? - related answer on how to properly programmatically submit a JSF based form.
I am developing a RESTful framework and am deciding how to handle an unsupported verb being called against a resource. For example, someone trying to PUT to a read-only resource.
My initial thought was a 404 error, but the error is not that the resource cannot be found, it exists, just the user is trying to use the resource incorrectly. Is there a more appropriate error code? What is the most common way in which this situation is handled?
Is it that you simply don't support a certain verb ie DELETE? In that case I'd use the following HTTP response code if someone uses a verb you don't support.
405 Method Not Allowed
A request was made of a resource using a request method not supported by that resource;[2] for example, using GET on a form which requires data to be presented via POST, or using PUT on a read-only resource. [source]
I don't think you would receive a request to your app at all if the incorrect verb were used (but that probably depends on which specific technologies you're using on the server side).
To be more helpful to potentially confused client connection attempts I suppose you could create a stub endpoint/action for each commonly incorrect verb, method combinations and then send back a friendly "use {verbname} instead for this request" text response, but I'd personally just invest a bit of time in better developer documentation : )
You could also seamlessly redirect to the correct action in those cases...
It seems common in the Rails community, at least, to respond to successful POST, PUT or DELETE requests by redirecting instead of returning success. For instance, if I PUT a legal change to my user profile, the idiomatic response would be a 302 Redirect to the profile page.
Isn't this wrong? Shouldn't we be returning 200 OK from the request? Or a 201 Created, in the case of a POST request? Either of those, in the HTTP/1.1 Status Definitions are allowed to (or required to) include a response, anyway.
I guess I'm wondering, before I go and "fix" my application, whether there is there a darn good reason why the community has gone the way of redirects instead of successful responses.
I'll assume, your use of the PUT verb notwithstanding, that you're talking about a web app that will be accessed primarily through the browser. In that case, the usual reason for following up a POST with a redirect is the post-redirect-get pattern, which avoids duplicate requests caused by a user refreshing or using the back and forward controls of their browser. It seems that in many instances this pattern is overloaded by redirecting not to a success page, but to the next most likely place the user would visit. I don't think either way you mention is necessarily wrong, but doing the redirect may be more user-friendly at the expense of not strictly adhering to the semantics of HTTP.
It's called the POST-Redirect-GET (PRG) pattern. This pattern will prevent clients from (accidently) re-executing non-idempotent requests when for example navigating forth and back in browser's history.
It's a good general web development practice which doesn't only apply on RoR. I'd just keep it as is.
In a perfect world, yes, probably. However HTTP clients and servers are a mess when it comes to standardization and don't always agree on proper protocol. Redirecting after a post helps avoid things like duplicate form submissions.