Uploaded image for project: 'Spring Framework'
  1. Spring Framework
  2. SPR-7345

HTTP 405 (Method not supported) returned when 404 Status (Not Found) was expected

    Details

    • Type: Bug
    • Status: Closed
    • Priority: Minor
    • Resolution: Fixed
    • Affects Version/s: 3.0.3
    • Fix Version/s: 3.0.4
    • Component/s: Web
    • Labels:
      None
    • Last commented by a User:
      true

      Description

      Scenario:

      • Sent a HTTP request for text/html content
      • @RequestMapping only matches text/plain content
      • A 405 status code was returned when I had expected a 404

      This can be reproduced by running the demo application here:
      https://src.springsource.org/svn/spring-samples/mvc-showcase

      Deploy the application can click on the "GET /simple/textonly" link to see the 405 returned. See the org.springframework.samples.mvc.simple.SimpleControllerRevisited for the @Controller implementation.

        Issue Links

          Activity

          Hide
          kdonald Keith Donald added a comment - - edited

          The way I implemented the "produces" contract was by using the "headers" attribute of @RequestMapping:

          @RequestMapping(value="/simple/textonly", method=RequestMethod.GET, headers="Accept=text/plain")
          public @ResponseBody String simple() {
          	return "Hello world!";
          }

          Thinking about it more , this arguably isn't the same as saying @Produces("text/plain"). Specifically, with the code above, if the Accept header was not set to "text/plain", one would expect this @RequestMapping rule to never match, and RESOURCE_NOT_FOUND (404) to be returned. OTOH, with @Produces, you're explicitly setting the acceptable content types; if a client does not support one of them, you'd expect the server to respond with NOT_ACCEPTABLE (406) then.

          What seems like a bug is the fact a METHOD_NOT_SUPPORTED (405) is currently returned.

          Do we need a separate New Feature JIRA for @Produces-equivalent functionality?

          Show
          kdonald Keith Donald added a comment - - edited The way I implemented the "produces" contract was by using the "headers" attribute of @RequestMapping: @RequestMapping(value="/simple/textonly", method=RequestMethod.GET, headers="Accept=text/plain") public @ResponseBody String simple() { return "Hello world!"; } Thinking about it more , this arguably isn't the same as saying @Produces("text/plain"). Specifically, with the code above, if the Accept header was not set to "text/plain", one would expect this @RequestMapping rule to never match, and RESOURCE_NOT_FOUND (404) to be returned. OTOH, with @Produces, you're explicitly setting the acceptable content types; if a client does not support one of them, you'd expect the server to respond with NOT_ACCEPTABLE (406) then. What seems like a bug is the fact a METHOD_NOT_SUPPORTED (405) is currently returned. Do we need a separate New Feature JIRA for @Produces-equivalent functionality?

            People

            • Assignee:
              arjen.poutsma Arjen Poutsma
              Reporter:
              kdonald Keith Donald
              Last updater:
              Trevor Marshall
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:
                Days since last comment:
                7 years, 34 weeks, 1 day ago

                Time Tracking

                Estimated:
                Original Estimate - Not Specified
                Not Specified
                Remaining:
                Remaining Estimate - 0d
                0d
                Logged:
                Time Spent - 2h 11m
                2h 11m