simon
12월 12, 2022, 11:39오후
1
최근에 로컬 Discourse와 WordPress 사이트를 연결하려고 할 때 다음과 같은 오류가 발생하고 있습니다:
cURL error 61: Unrecognized content encoding type. libcurl understands deflate, gzip, br content encodings.
문제는 로컬 개발 환경에서 Discourse가 다음과 같은 헤더를 설정하고 있는 것 같습니다:
content-encoding: null
제 로컬 Apache 서버는 content-encoding: null 헤더를 처리할 수 없습니다. 제 wp shell에서 wp_remote_get("http://localhost:4200/site.json") 요청은 위에서 언급한 오류로 실패하지만, Discourse 프로덕션 사이트(예: wp_remote_get("https://meta.discourse.org/site.json"))에 대한 요청은 문제없이 작동합니다.
이 문제에 대한 임시 해결책은 로컬 Discourse 설치 환경에서 이 줄을 주석 처리하는 것입니다: https://github.com/discourse/discourse/blob/main/app/assets/javascripts/bootstrap-json/index.js#L330 . 하지만 이는 좋은 해결책이 아닙니다. 로컬호스트에서 실행되는 Discourse 사이트 연결 시 비슷한 문제를 겪은 분이 계신가요? content-encoding: null 헤더가 포함된 응답을 수락하도록 로컬 Apache 서버를 구성하는 방법에 대한 제안이 있으신가요?
이 문제가 언제 시작되었는지 정확히 알았으면 좋겠습니다. 아마도 Discourse가 content-encoding: null 헤더를 설정하기 시작한 시점부터 발생하고 있을 수도 있습니다.
수정: 이 문제는 Ubuntu 22.04.1에서 발생하고 있습니다. Curl 버전: curl 7.81.0. PHP 버전: 8.1.2. 이는 전혀 긴급하지는 않지만, 어떤 일이 일어나고 있는지 궁금합니다.
angus
12월 14, 2022, 9:32오전
2
흥미롭네요! 어딘가에서 막연히 느껴지는 것이 있지만, 지금은 정확히 떠오르지 않습니다. 하지만 제 첫 번째 질문은 Discourse가 content-encoding 헤더를 null로 설정하는 곳이 어디이며, 왜 그렇게 하는가입니다.
이것은 확실히 “개발 전용” 문제인 것 같습니다. 다음 내용과 관련이 있어 보입니다.
After doing some digging through the source, I found two environment variables that help:
PRINT_EXCEPTIONS - shows all exceptions, maybe too noisy to be valuable but it helped
RAILS_LOGS_STDOUT - logs everything to console which is what I was looking for above
These helped confirm that there wasn’t an error occurring within Rails nor my theme’s SCSS.
Apparently there was some gzip component stuck between ember and Rails. I’m not sure how this got there, but when the headers Content-Encoding …
simon
8월 3, 2023, 10:38오후
3
코드가 업데이트됨에 따라 줄 번호는 변경됩니다. 참고로, WP Discourse 플러그인을 사용하여 로컬 개발을 할 때 주석 처리해야 하는 Discourse 코드 내의 해당 줄은 다음과 같습니다:
res.set("content-encoding", null);
Discourse 코드 내에서 정확히 어떤 일이 일어나고 있는지 완전히 추적해 보지는 않았지만, 해당 줄을 주석 처리하면 Discourse가 응답을 gzip으로 압축하는 것으로 보입니다:
["content-encoding"]=>
array(1) {
[0]=>
string(4) "gzip"
}
이것이 제 개발 환경에서 문제를 일으키는 것 같지는 않습니다.
simon
5월 28, 2024, 6:23오후
4
로컬 WordPress와 Discourse 사이트를 연결할 때마다 이 문제를 다시 마주하게 됩니다.
참고로, res.set("content-encoding", null); 라인은 현재 다음 위치에 있습니다:
response.headers.forEach((value, header) => {
if (header === "set-cookie") {
// Special handling to get array of multiple Set-Cookie header values
// per https://github.com/node-fetch/node-fetch/issues/251#issuecomment-428143940
res.set("set-cookie", response.headers.raw()["set-cookie"]);
} else {
res.set(header, value);
}
});
res.set("content-encoding", null);
const location = response.headers.get("location");
if (location) {
const newLocation = location.replace(proxy, `http://${originalHost}`);
res.set("location", newLocation);
}
const csp = response.headers.get("content-security-policy");
if (csp && !csp.includes("'strict-dynamic'")) {
const emberCliAdditions = [
해당 라인을 주석 처리하면 문제가 해결됩니다.
다른 사용자들에게 영향이 없는 것이라면, 제 로컬 개발 환경에 설정 오류가 있는 것일 수 있습니다. 하지만 "content-encoding"을 null로 설정하는 것은 여전히 잘못된 것 같습니다. 이는 헤더에 유효한 값이 아니기 때문입니다.
angus
5월 28, 2024, 7:12오후
5
사실 저는 최근 ActivityPub 플러그인 컨텍스트에서, 로컬에서 WordPress의 ActivityPub 플러그인과 Discourse 간의 ActivityPub 통합을 테스트할 때 이 문제를 경험했습니다.
이것이 discourse/discourse의 개발 단계 문제일 뿐이며, PHP 리모트 환경에서만 나타나는 것 같아(PHP 요청 함수가 동작하는 방식 때문일 수 있습니다) 카테고리를 #dev로 변경했습니다.
지금 정확히 기억나지 않지만, 프로덕션 환경에서는 다른 곳에서 설정이 이루어진다는 결론에 도달한 것 같습니다. 내일 다시 기억해 보겠습니다.