Content Negotiation - .xml suffix no longer working?

1

I’m migrating a VERY old .Net Framework/ServiceStack 5.x solution to NET10/ServiceStack10 and have run into a problem I can’t find a solution for: the content negotiation described the docs (Routing) doesn’t seem to be working, specifically adding “.xml” to the end of my route to force XML serialization results in a 405 Method Not Allowed response. Interestingly, adding “?format=xml” does still work, but that’s not how all of our clients that consume these services are making requests. Note that I tried including a “ContentType: application/xml” and I still get a 405 response.

To test this, I created a new site using “x new” and modified the Hello service to meet our current implementation:

[Route("/hello", "POST")]
public class Hello : IGet, IReturn<HelloResponse>
{
    public string? Name { get; set; }
}

public class HelloResponse
{
    public string? Result { get; set; }
}

ServiceInterface:

public class MyServices : Service
{
    public object Post(Hello request)
    {
        return new HelloResponse { Result = $"Hello, {request.Name}!" };
    }
}

Here’s an example request in Postman:

image
image523×542 25.6 KB

Am I missing some configuration in AppHost setup? I confirmed that AllowRouteContentTypeExtensions is true on startup.

2

If you want to perform a POST your DTO should be using IPost interface marker, not IGet:

public class Hello : IPost, IReturn<HelloResponse> {}
3

Apologies, I missed that part in creating my small repo to determine if anything else I was doing in the solution might be affecting things. I’ve changed that interface marker as suggested but the behavior is still the same: 405 response code when I use the “.xml” suffix on the Post URL, as in my screenshot above. Here’s my updated service models:

[Route(“/hello”, “POST”)]
public class Hello : IPost, IReturn
{
public string? Name { get; set; }
}

public class HelloResponse
{
public string? Result { get; set; }
}

This was definitely working in a .Net Framework-based solution, so it feels like something in ASP.NET Core is preventing the routing from getting into the Service Stack pipeline. Can you confirm on your end?

4

The new templates default to using Endpoint Routing which requires every route to be explicitly defined. To avoid route pollution it only registers explicit routes for GET API pre-defined routes, e.g. GET /*.xml

You can disable Endpoint Routing and revert back to using ServiceStack Routing by commenting out:

app.UseServiceStack(new AppHost(), options => {
    // options.MapEndpoints();
});

I don’t use Postman since most IDEs have support for .http files which you can include with your project:

hello_xml.http

### POST /hello.xml
POST https://localhost:5001/hello.xml
Content-Type: application/xml

<Hello xmlns:i="http://www.w3.org/2001/XMLSchema-instance" 
       xmlns="http://schemas.datacontract.org/2004/07/XmlTest.ServiceModel">
    <Name>World</Name>
</Hello>
###

In a new project this returns:

HTTP/1.1 200 OK
Connection: close
Content-Type: application/xml
Date: Fri, 20 Feb 2026 03:20:48 GMT
Server: Kestrel
Transfer-Encoding: chunked
Vary: Accept
X-Powered-By: ServiceStack/10.07 NET10/Linux/net10/BU

<?xml version="1.0" encoding="utf-8"?>
<HelloResponse 
  xmlns:i="http://www.w3.org/2001/XMLSchema-instance" 
  xmlns="http://schemas.datacontract.org/2004/07/XmlTest.ServiceModel">
  <Result>Hello, World!</Result>
</HelloResponse>
5

Perfection, that was exactly what I needed. Commenting out the line indicated in program.cs allows our current clients to make requests with “.xml” suffixes, so things look like they’re working as expected now. Are there any other ramifications of not using Endpoint Routing?

Thanks again for the quick response, very appreciated!

6

Endpoint Routing is the default and does allow for greater integration with other ASP .NET Core middleware, e,g. for the latest OpenAPI v3 support we’re using ASP .NET Core’s recommended OpenAPI Metadata + UI solutions with ServiceStack API Routes since it’s able to get the metadata from the registered Endpoint Routes which is the primary benefit of it at the moment.

Either way I’ve just checked in support for *.{ext} routes for other (i.e. non GET) routes in the latest v10.0.7 that’s now available in pre-release packages. So if you use the pre-release packages you should also be able to use Endpoint Routing as well.

7

Once again, you’re amazing. THANK YOU for the quick release on the new pre-release version. I have updated to 10.0.7 and was able to enable Endpoint Routing again and POSTs with an .xml suffix are confirmed working as expected again.

2 Likes