Направляющие при обслуживании единорогом генерируют неправильный цифровой отпечаток для предварительно скомпилированных активов

У меня есть рабочий сервер с nginx-> единорог-> направляющие. Я предварительно компилирую активы, который помещает активы в общественность/активы с цифровым отпечатком (хеш), добавленный к имени файла. Однако, когда веб-страницу требуют, ссылки на application.css и application.js активы будут иметь неправильный цифровой отпечаток. Например, помощник направляющих stylesheet_link_tag генерирует имя файла, которое не существует в общественности/активах на сервере, потому что требуемый цифровой отпечаток не соответствует предварительно скомпилированному. Активы изображения хорошо работают (соответствие цифровых отпечатков).

Диагностируя это, я предварительно скомпилировал активы на своей локальной машине, и цифровой отпечаток соответствует предварительно скомпилированному цифровому отпечатку на моем сервере. Кроме того, при выполнении локально с webrick в производственном режиме, все работает. Я затем пытался выполнить webrick на своем сервере, который работал, заставляя меня думать, что единорог является источником проблемы.

Я решил эту проблему стартовым единорогом с - no-default-middleware (или-N) опция, и это заставляет единорога вести себя как ожидалось относительно предварительно скомпилированных активов. Мое понимание - то, что это говорит единорогу не загружать набор по умолчанию промежуточного программного обеспечения Стойки, которое он иначе загрузил бы. Однако я действительно не понимаю, почему это решает проблему, или что идет не так, как надо во-первых. Что продолжается?

Некоторые специфические особенности: Ubuntu 12.04, направляющие 4.0.1, Ruby 2.1.0, загружается 3.0 со сторонней темой

Обновление:

Причиной, что я не верю этому, является nginx проблема, то, что, когда я запрашиваю страницу от браузера и затем просматриваю источник, имя файла для application.css файла имеет цифровой отпечаток, таким образом, это на самом деле похоже на приложение-3855b1928b94aa5bff5e1dac1aa56882.css. Это не соответствует реальному цифровому отпечатку файла на моем сервере. Я убежден, что цифровой отпечаток на сервере корректен, потому что я получаю тот же цифровой отпечаток на своей локальной машине разработки. Таким образом, клиент загружает веб-страницу, затем прося, чтобы сервер для .css файла... nginx получил тот запрос, но не мог найти .css файл, потому что это на самом деле не там, таким образом, nginx ведет себя как ожидалось.

Цифровой отпечаток сгенерирован дважды: Однажды, когда я предварительно компилирую активы, который работает правильно (вполне уверенный), и происходит без участия единорога. И во второй раз, когда направляющие в контексте рабочего единорога видит stylesheet_link_tag помощника и на лету вычисляет цифровой отпечаток (я думаю, что это - то, что он делает), который по некоторым причинам генерирует неправильный цифровой отпечаток. Этот тот же процесс происходит, если я заменяю единорога webrick на том же самом сервере, но в этом случае соответствие цифровых отпечатков. Если я запускаю единорога с флага-N, соответствия цифровых отпечатков, но я не знаю, почему это имеет значение, и я не знаю, почему никто больше, кажется, не должен делать этого.