/posts 페이지를 방문할 때 이 문제가 보고되지 않은 것 같습니다. 브라우저에는 예: Discourse Meta
이렇게 표시됩니다.
반드시 https://meta.discourse.org/posts1
에서와 같은 애플리케이션 오류 페이지가 표시되어야 합니다.
이렇게 표시됩니다.
반드시 https://meta.discourse.org/posts1
에서와 같은 애플리케이션 오류 페이지가 표시되어야 합니다.
1개의 좋아요
첫 번째 링크를 따라가면 오류 페이지가 표시됩니다. 특정 브라우저에서만 이런 현상이 발생하는 건가요?
Chrome, Firefox, Safari의 사파리 모드에서 링크를 테스트했습니다.
링크를 클릭하면 “오류!” 페이지가 표시됩니다. 하지만 해당 페이지를 새로고침하거나 새 탭에 URL을 입력하면 작동하지 않습니다.
406 오류를 반환하는 것으로 보입니다. Ember 앱에서는 이를 404처럼 처리하지만, 브라우저를 새로고침하면 브라우저가 다르게 보고합니다.
어떤 경우든 오류이며, UX에 해당 URL로 연결되는 링크가 없으므로 왜 문제가 되는지 명확하지 않습니다.
질문을 수정합니다 - https://meta.discourse.org/posts가 존재하지 않는 페이지로 간주될 때, 왜 406 응답과 빈 페이지가 반환되는지 궁금합니다. 404 응답과 ‘Oops’ 메시지가 더 합리적입니다.
Chrome 개발자 도구의 네트워크 탭에서 406 응답 코드를 확인했습니다. ‘Oops’ 페이지는 매우 가끔 볼 수 있습니다. ‘Oops’ 페이지를 표시하는 것은 합리적입니다.
제 질문은 어떤 오류가 발생하든, 빈 페이지 대신 사용자 친화적인 오류 메시지(예: ‘Oops’ 페이지와 같은)를 표시하는 것은 애플리케이션의 책임이라는 것입니다. 406 응답의 경우, 애플리케이션에조차 도달하지 못한다고 추측됩니다. 이는 애플리케이션 앞에 있는 웹 서버나 프록시 서버와 같은 서비스에서 보고된 오류일 가능성이 높습니다.
문제가 있는 링크를 애플리케이션이 생성한 것인가요?
discourse/config/routes.rb at main · discourse/discourse · GitHub 을 살펴보니 유효한 라우트가 아닌 것 같습니다.
유효하지 않은 라우트에서 시작하면, Rails가 잘못된 URL임을 알려기 위해 전체 Ember 애플리케이션을 전송하지는 않습니다.
제 판단이 틀렸네요. https://meta.discourse.org/bananas 는 oops 페이지가 로드됩니다. /posts/:id/xxx 가 유효한 라우트이기 때문인 것 같습니다.
네. 나머지 파라미터를 제거한 후 이 맨 상태의 /posts URL을 얻게 된 것입니다 (다만, /posts/:id/xxx 페이지를 어디서 봤는지 지금은 기억이 나지 않습니다). /posts가 사용자의 모든 게시물을 위한 유효한 라우트라고 생각했습니다. 이는 Discourse가 처리하지 않는 경계 사례일 수 있습니다.
1개의 좋아요
/posts가 모든 게시물을 반환할 것이라고 기대했지만, 시스템의 모든 게시물을 반환하는 것은 사실상 쓸모없습니다. 본인의 게시물은 https://meta.discourse.org/my/activity에서 확인할 수 있습니다.
1개의 좋아요
이 부분에 대해 어느 정도 동의합니다. /posts가 빈 페이지를 반환하는 것이 Discourse의 버그인가요? 이것이 정상적인 동작인지 궁금할 뿐이며, 이 문제가 반드시 수정되어야 한다고 고집하지는 않습니다. 아마도 Discourse 팀의 추가적인 논의가 필요할지도 모릅니다. 
이 이슈를 #pr-welcome으로 표시하겠습니다. 유효한 문제이지만 우선순위는 매우 낮습니다.
5개의 좋아요