Маршруты .NET Core Web API возвращают 404 только в Linux?

Если я соберу свое приложение .NET Core из каталога решения на моей машине Windows dev, например:

dotnet publish --configuration Release --output \myproject --self-contained --runtime win7-x64

Я могу запустить это и попасть в свою конечную точку http://localhost:5000/api/auth/login, не беспокойтесь.

Я делаю почти идентичную публикацию на машине Ubuntu 18.04 LTS:

dotnet publish --configuration Release --output /ubuntu-myproject --self-contained --runtime ubuntu-x64

... скопируйте файлы в папку, установите соответствующий файл проекта в исполняемый файл и запустите его, он точно так же начнет прослушивать localhost: 5000. Статические страницы (например, мой базовый index.html) обслуживаются... но все мои конечные точки API возвращают 404. Я ломаю голову, почему так. Кажется, нет никаких сообщений об ошибках или чего-то еще, как будто маршруты просто не зарегистрированы или что-то в этом роде.

Может ли кто-нибудь подсказать мне, почему это может быть так?

Это было создано с помощью .NET Core SDK 2.1.302.

ОБНОВЛЕНИЕ

Я установил ведение журнала на отладку и использовал маршрут, который, как известно, работает везде, кроме этой машины с Linux: GET /api/groups. Я вызвал это из окна командной строки на Linux-машине:

curl -I  http://localhost:5000/api/groups

мой ответ был таким:

HTTP/1.1 404 Not Found 
Date: Wed, 01 Aug 2018 02:15:48 GMT 
Server: Kestrel

в моем файле журнала была следующая информация о событии:

2018/08/01 02:15:49.241|INFO|Request starting HTTP/1.1 HEAD http://localhost:5000/api/groups   |Microsoft.AspNetCore.Hosting.Internal.WebHost|Protocol=HTTP/1.1, Method=HEAD, ContentType=, ContentLength=, Scheme=http, Host=localhost:5000, PathBase=, Path=/api/groups, QueryString=, EventId_Id=1, EventId_Name=, EventId=1
2018/08/01 02:15:49.535|INFO|Request finished in 292.2005ms 404  |Microsoft.AspNetCore.Hosting.Internal.WebHost|ElapsedMilliseconds=292.2005, StatusCode=404, ContentType=, EventId_Id=2, EventId_Name=, EventId=2

person Jeremy Holovacs    schedule 31.07.2018    source источник
comment
Как вы используете и запускаете .NET в Linux?   -  person Rob    schedule 31.07.2018
comment
@Rob, это веб-приложение .NET Core, автономное с Kestrel.   -  person Jeremy Holovacs    schedule 31.07.2018
comment
Вы пробовали это с другой средой выполнения, например. ubuntu.18.04? У меня были проблемы с использованием «базовой» среды выполнения, но когда я использовал конкретную, все работало нормально. Последний список поддерживаемых сред выполнения находится здесь   -  person Simply Ged    schedule 31.07.2018
comment
Попробуйте войти в системный журнал с помощью Syslog.Framework.Logging и посмотрите, предоставляется ли дополнительная информация.   -  person Mark G    schedule 31.07.2018
comment
@SimplyGed Я не знал, что среда выполнения доступна; Я попробую это.   -  person Jeremy Holovacs    schedule 31.07.2018
comment
@MarkG Я также посмотрю, даст ли это мне больше информации.   -  person Jeremy Holovacs    schedule 31.07.2018
comment
@SimplyGed, который не является допустимой целью среды выполнения?   -  person Jeremy Holovacs    schedule 31.07.2018
comment
@SimplyGed Я попробовал это со средой выполнения Ubuntu 18.04 x64, у меня все еще та же проблема.   -  person Jeremy Holovacs    schedule 01.08.2018
comment
@MarkG У меня подключен NLog. Я установил уровень журнала для отладки, и все, что выходит, это 404.   -  person Jeremy Holovacs    schedule 01.08.2018
comment
@JeremyHolovacs Вы не видите ничего похожего на то, что запрос успешно сопоставил маршрут? Что именно показывает?   -  person Mark G    schedule 01.08.2018
comment
@MarkG Я обновил свой пост с разбивкой того, что я вижу.   -  person Jeremy Holovacs    schedule 01.08.2018
comment
Можете открыть следующий выпуск на GitHub: github.com/Microsoft/aspnet-api- версия/вопросы/194   -  person Mixim    schedule 01.08.2018
comment
@Mixim, я не понимаю, о чем ты спрашиваешь? Вы предлагаете мне открыть тикет или предполагаете, что это разрешение тикета может решить мою проблему? Я не использую MapWhen... и кажется, что это будет проблемой независимо от того, на какой машине он работает.   -  person Jeremy Holovacs    schedule 01.08.2018
comment
@JeremyHolovacs По какой причине вы используете опцию -I в curl? Разве вам не понадобится HttpHead в дополнение к атрибуту HttpGet?   -  person Mark G    schedule 01.08.2018
comment
@MarkG, ты превзошел мои знания о завитке; Я только что погуглил, как проверить конечную точку RESTful. Однако я ожидаю, что при отсутствии соответствующей информации в заголовке я получу 401 или 403 вместо 404.   -  person Jeremy Holovacs    schedule 01.08.2018
comment
@JeremyHolovacs Попробуйте curl без опции -I. Используете ли вы маршрутизацию на основе соглашений или атрибутов? Можешь поделиться своим конфигом?   -  person Mark G    schedule 01.08.2018
comment
@MarkG Я использую маршрутизацию на основе атрибутов; На самом деле моей конфигурацией не так просто поделиться; каждый настроенный компонент находится в отдельном классе, чтобы класс запуска был умеренно коротким и чистым.   -  person Jeremy Holovacs    schedule 01.08.2018
comment
Я скажу, что мои тесты на завитки были вторичными после попытки выяснить, почему мой обратный прокси-сервер возвращал 404, поэтому я не думаю, что это проблема с тем, как я использую завиток, но я поэкспериментирую и дам вам знать .   -  person Jeremy Holovacs    schedule 01.08.2018


Ответы (1)


Итак, проблема здесь была на самом деле в двух вещах. Как предположил @MarkG, меня ввело в заблуждение мое неправильное предположение о том, как протестировать конечную точку API с помощью curl. Я не должен был использовать параметр -I, он отправлял неправильный запрос, поэтому я получил 404... другими словами, вместо отправки запроса GET /api/groups я отправлял HEAD /api/groups... который не был определенным маршрутом, и поэтому должен возвращать ошибку 404.

Вторая проблема заключалась в том, что мой прокси-сервер nginx был неправильно настроен, поэтому внешне все мои конечные точки /api/ также возвращали 404 по другой причине. В сочетании с моими плохими запросами curl казалось, что nginx был правильно настроен, и моя служба API просто возвращала 404 для всего... хотя на самом деле это просто я ошибался на нескольких уровнях.

person Jeremy Holovacs    schedule 02.08.2018
comment
Я знаю, что прошло некоторое время, но не могли бы вы дать лучшее объяснение того, что вы сделали, чтобы решить эту проблему? Я сейчас в той же лодке, и, к сожалению, ваше объяснение выше немного освещает точные детали. - person Jeff Turner; 24.04.2019
comment
@JeffTurner ну, главное, что я сделал, это исправил настройки nginx. Это не то, что вписывается в комментарий, но есть несколько руководств о том, как это сделать. - person Jeremy Holovacs; 24.04.2019