Deploying ASP.NET Core Docker project - getting a 405 error (in my IIS the web request works). How to solve?
I am using .net core 3.1 . With the help of docker , I uploaded the code to heroku . But when I make a web request, I get a 405 error on all endpoints . (I can't see more details of the error)
Use Get
:
http://xxxx.herokuapp.com/api/pqrs/test/1315315
From Visual Studio Code, also locally from my IIS, everything works fine. But the problem occurs when I deploy to the server.
What am I doing wrong? Here is the code of my controller :
using System;
using System.Collections.Generic;
using System.IdentityModel.Tokens.Jwt;
using System.Linq;
using System.Security.Claims;
using System.Text;
using System.Threading.Tasks;
using apiPQR.Contexts;
using apiPQR.Entities;
using apiPQR.Models;
using Microsoft.AspNetCore.Authentication.JwtBearer;
using Microsoft.AspNetCore.Authorization;
using Microsoft.AspNetCore.Mvc;
using Microsoft.Extensions.Configuration;
using Microsoft.IdentityModel.Tokens;
namespace apiPQR.Controllers
{
[ApiController]
[Route("api/[controller]")]
public class Pqrs : Controller
{
private readonly AppDbContext context;
private readonly IConfiguration configuration;
public Pqrs(AppDbContext context, IConfiguration configuration)
{
this.context = context;
this.configuration = configuration;
}
[HttpGet, Route("test/{id}")]
public PQRS Get(int id)
{
var num_pqrs = context.PQRS.FirstOrDefault(p => p.num_solicitud==id);
return num_pqrs;
}
}
}
renew:
this is mineDockerfile
#See https://aka.ms/containerfastmode to understand how Visual Studio uses this Dockerfile to build your images for faster debugging.
FROM mcr.microsoft.com/dotnet/core/aspnet:3.1-buster-slim AS base
WORKDIR /app
EXPOSE 80
EXPOSE 443
FROM mcr.microsoft.com/dotnet/core/sdk:3.1-buster AS build
WORKDIR /src
COPY ["apiPQR.csproj", ""]
RUN dotnet restore "./apiPQR.csproj"
COPY . .
WORKDIR "/src/."
RUN dotnet build "apiPQR.csproj" -c Release -o /app/build
FROM build AS publish
RUN dotnet publish "apiPQR.csproj" -c Release -o /app/publish
FROM base AS final
WORKDIR /app
COPY --from=publish /app/publish .
ENTRYPOINT ["dotnet", "apiPQR.dll"]
I've never seen CORS issues or anything like that. just 405
wrong.
Error code 405 means "Method Not Allowed" . The request was blocked by the server.
First I would analyze if the problem is really on the hosting side (heroku) or in your docker configuration.
The fact that your application is running in IIS on your local machine is an important prerequisite, but it doesn't mean it will also run in docker. So I'll go ahead with your docker file: run a docker image locally before deploying it to the host (heroku) .
One way is to enable it for your project in Visual Studio, another way is to use the command line :
docker container run --name [container_name] [docker_image]
Once running, check the port mapping by
docker ps
Then, try to access it via
http://localhost:<add your port>/<add your path here>
or (if you are using SSL/TLS)
https://localhost:<add your port>/<add your path here>
If you find that you get a 405, you can proceed as follows:
Check the configuration of the web server in the docker container, does it allow the required HTTP verbs (GET, PUT, POST, DELETE)? These are required in RESTful APIs . In your example you are only using GET - so check that.
Also check if any CORS settings are missing . This may also block the request.
It's also worth reading Microsoft's documentation on Containerized Apps to understand how Visual Studio creates containers for your applications. Make sure you've read the section on SSL -enabled ASP.NET Core applications , which describes the setup of Kestrel , the web server in use in the ASP.NET Core world.
If you find your docker is working fine locally, continue on the hosting side:
Are there firewall settings blocking your request? Also check the firewall rules for the host "heroku". If you're using SSL/TLS, you'll need to provide a certificate - as described in the link above.
Quoting from the link above:
"ASP.NET Core looks under the Https folder for a certificate that matches the assembly name, which is why it maps to the container in that path. The
certificate path and password can also be used using environment variables (i.e. ASPNETCORE_Kestrel__Certificates__Default__Path and ASPNETCORE_Kestrel__Certificates__Default__Password)
or in User secret json file"