서브폴더에서 사이트 상대 경로가 클라이언트 측에서 잘못 재작성됩니다

이전에는 정상적으로 작동했지만, 최근 업데이트 이후 다시 문제가 발생한 것 같습니다.

상대 경로 링크 추가

[Full version 1.9.2 change history](/downloads/continuaci/continua-ci-version-history-v192)

를 추가하면 링크는 올바르게 렌더링되고 마크업도 정확하지만, 링크를 클릭하면 다음과 같이 변환됩니다.

https://www.finalbuilder.com/forums/downloads/continuaci/continua-ci-version-history-v192

참고로, 저희 discourse 인스턴스는 forums 하위 폴더에 설치되어 있습니다.

올해早些时候 이 영역에서 일부 변경 사항이 있었던 것으로 보이며, 이것이 관련이 있을 수 있습니다.

현재 2.8 beta1 버전을 사용 중입니다 - Commits · discourse/discourse · GitHub

3개의 좋아요

상대 링크는 서브폴더 루트를 기준으로 해석된다고 보는 것이 타당하다고 생각합니다. 따라서 포럼 외부로 연결되는 링크를 사용하려면 완전한 URL(절대 경로)을 사용해야 합니다.

대안으로, 영구 링크 라우팅을 /forum/downloads/*에서 https://example.com/downloads/*로 설정할 수 있을 것 같습니다.

2개의 좋아요

이전에는 작동했는데 왜 변경된 건가요?

상대 경로가 앵커(absolute path)로 지정된 경우, 예를 들어 /downloads라면, HTML/HTTP 환경에서는 사이트의 루트(root)를 의미하는 것이 일반적이지 서브폴더의 루트를 의미하는 것은 아니라고 생각됩니다.

1개의 좋아요

즉, 메인 웹사이트에 /t/something으로 시작하는 링크가 있다면, 그것이 Discourse 링크인지 메인 웹사이트 링크인지 어떻게 구별할 수 있을까요?

1개의 좋아요

이것은 /forums/t/something으로 작성됩니다. 이는 포럼 게시글을 작성하는 일반 사용자가 기대하는 형태입니다. 대부분의 웹사이트가 이렇게 작동하므로, 누가 /t/something을 입력해야 하는지 알겠습니까?

1개의 좋아요

여기서는 @RGJ님의 의견에 동의합니다. 여러 애플리케이션이 동일한 서브폴더 접두어를 공유하는 것은 문제를 초래하기 쉽습니다.

저에게는 "수정 불가"입니다.

2개의 좋아요

진짜요? /로 시작하는 URL을 작성하면 설계상 사이트의 루트에 위치하게 됩니다 - HTML 링크가 작동하는 방식을 재정의하시는 건가요?

이것은 최근의 호환성 깨짐(breaking change)이 발생하기 전까지 우리 사이트에서 2년 반 동안 정상적으로 작동했습니다.

1개의 좋아요

바로 그 점이 문제입니다. Discourse가 여러 애플리케이션에 동일한 접두사 /forums를 추가하고 있으며, 이로 인해 aforementioned(앞서 언급된) 문제가 발생하고 있습니다. 게시물에 입력된 URL을 왜 변경해야 하는지 이해가 되지 않습니다.

1개의 좋아요

현재 이 문제를 조사 중이며, 다음과 같은 수정 사항과 관련이 있을 수 있습니다:

서브폴더 설정과 무관하게 acme.com의 /jobs 링크는 acme.com/jobs로 이동해야 한다는 점에 동의합니다. acme.com/forum/jobs로 이동해서는 안 됩니다.

7개의 좋아요

링크된 커밋보다 약간 늦은 시점에 get-url.js에 마지막 커밋을 추가했습니다.

사용자가 직접 입력한 링크는 재작성되지 않아야 한다는 데 동의합니다. 이러한 시나리오에서는 getURL을 호출하지 않는 것이 맞을까요? getURL은 Discourse 기본 라우트를 서브폴더 설정으로 "변환"하는 용도로 사용되어야 한다고 생각합니다. 실제로 서브폴더 접두사 추가를 명시적으로 기대하는 테스트가 있습니다:

도움이 필요하시면 말씀해 주세요.

오늘 오후에 이 문제를 조사했고, 해당 PR에 수정 사항을 반영했습니다:

불행히도 우리의 routeTo 코드는 상대 URL과 함께 작동하도록 설계되어 있습니다. 따라서 url.routeTo("/cool")를 호출하고 sub라는 서브폴더가 설정된 경우, /cool이 상대적으로 보임에도 불구하고 /sub/cool로 재작성됩니다. 이것이 올바른 동작이라고 생각하지는 않지만, 많은 코드가 이 동작에 의존하고 있을 것 같습니다.

다행히 이번 경우에는 클릭 트래커가 해당 URL을 내부 URL로 오인하여 리다이렉트를 수행하고 있었습니다. 내부 링크가 동일한 접두사를 사용하는지 확인하는 검사를 추가하고 테스트를 정리했습니다. 정상적으로 작동하는 것 같습니다.

하지만 어떻게 회귀(regression)가 발생했는지는 전혀 알 수 없습니다 - git blame을 시도해 보았지만 아무것도 나오지 않았습니다.

6개의 좋아요

이것이 관련이 있는지 확실하지는 않지만, 업데이트를 적용한 후 링크 편집기가 더 이상 작동하지 않습니다(빈 상태로 표시되거나 필드가 분리되지 않음).

이것은 더 나빠진 것 같습니다.

링크를 추가하면
[forum relative link](/forums/t/continua-ci-v1-9-2-664-released/7058)

다음과 같이 처리됩니다.
[forum relative link](https:///forums/t/continua-ci-v1-9-2-664-released/7058)

이 경우 href 속성 없이 렌더링됩니다.

참고로 위의 테스트는 Commits · discourse/discourse · GitHub 에서 수행되었습니다.

또한, /downloads와 같은 같은 사이트 내 상대 링크가 외부 링크로 처리되어 새 브라우저 탭에서 열립니다. 이는 큰 문제가 아닙니다.

또한, 큰 문제는 아니지만, 제가 그랬듯이 포럼 게시물 링크 끝에 있는 게시물 ID를 제거하면, 예를 들어 이 링크를 클릭할 때 브라우저 히스토리가 사라집니다.

불행히도 이 문제를 재현할 수 없습니다. 로컬에서 동일한 링크를 사용하면 올바르게 처리됩니다. 또한 제 패치는 링크가 HTML로 작성되는 방식을 변경하지 않으며, 링크를 클릭했을 때 발생하는 동작만 처리합니다.

이미 이 문제를 검토하고 있다고 생각합니다. 감사합니다:

2개의 좋아요