Score:0

วิธีแก้ปัญหา 400 Bad Request "ไคลเอ็นต์ส่งวิธีที่ไม่ถูกต้องขณะอ่านบรรทัดคำขอไคลเอ็นต์"

ธง cn

ฉันได้ตั้งค่า nginx เพื่อยุติการเชื่อมต่อ SSL และส่งต่อคำขอไปยังแบ็กเอนด์ http ไคลเอนต์สร้างคำขอพื้นหลังจำนวนหนึ่ง ซึ่งหนึ่งในนั้นล้มเหลวด้วย 400 คำขอไม่ถูกต้อง เมื่อใดก็ตามที่พยายามเจรจาการเชื่อมต่อ SSL หากไม่จำเป็นต้องเจรจาการเชื่อมต่อ - เช่น หากคำขอพื้นหลังอื่นเพิ่งโพสต์สำเร็จ คำขอนั้นสำเร็จ การตรวจสอบแท็บเครือข่าย Chrome ไม่พบความแตกต่างระหว่างคำขอที่สำเร็จและคำขอที่ล้มเหลว การเดินทางของฉันถูกโพสต์ที่นี่ใน รายงานข้อบกพร่องนี้แต่นี่คือสิ่งที่ฉันกลั่นมาได้จนถึงตอนนี้:

การเชื่อมต่อ SSL

เมื่อคำขอปัญหาสำเร็จ ฉันสามารถบอกได้ว่าไม่จำเป็นต้องเจรจาการเชื่อมต่อ SSL โดยดูที่แท็บเวลาของคำขอเครือข่าย (ใน Chrome): เวลา - คำขอสำเร็จ

ในทางกลับกัน เมื่อใดก็ตามที่คำขอล้มเหลว ฉันเห็นว่าคำขอนั้นพยายามต่อรองการเชื่อมต่อ SSL ดังที่เห็นในภาพนี้: เวลา - คำขอล้มเหลว

การจัดการ Nginx

จากการตรวจสอบบันทึกการเข้าถึงแอปพลิเคชัน ฉันได้พิจารณาแล้วว่าเป็น nginx ที่ส่งคืนไฟล์ 400 คำขอไม่ถูกต้อง ข้อผิดพลาด และไม่ใช่แอปพลิเคชัน HTTPเมื่อคำขอล้มเหลว บันทึก nginx ทั้งหมดจะเป็นเนื้อความ POST ค่อนข้างมากกว่า วิธี HTTP และ URL ตามปกติ (ฉันยังไม่ได้ปรับแต่งรูปแบบบันทึก nginx)

ฉันเปิดการดีบักในบันทึกข้อผิดพลาด nginx (ด้วยบรรทัด error_log /var/log/nginx/error.log ดีบัก;). สิ่งนี้ทำให้ฉันเห็นสิ่งที่เกิดขึ้นระหว่างการเจรจา SSL (แม้ว่าฉันจะไม่เข้าใจก็ตาม)

ดังที่ฉันได้กล่าวไว้สั้น ๆ ข้างต้น มีคำขอพื้นหลังอื่น ๆ ที่ประสบความสำเร็จ แม้ว่าจะเรียกใช้น้อยกว่าก็ตาม หลังจากคำขอใดๆ สำเร็จ คำขอทั้งหมดจะสำเร็จในช่วงระยะเวลาหนึ่ง (จนกว่าจะต้องมีการเจรจาการเชื่อมต่อ SSL)

นอกจากนี้ ถ้าฉันใช้ คัดลอกเป็นขด การทำงานจาก Chrome และเรียกใช้คำขอเป็นคำขอ cURL ก็จะสำเร็จเสมอ ครั้งเดียวที่ฉันสังเกตว่าล้มเหลวคือเมื่อเบราว์เซอร์ส่งคำขอ

บันทึกการดีบัก Nginx

นี่คือบิตที่เกี่ยวข้องจากคำขอ SSL ที่สำเร็จในบันทึก:

22/10/2021 20:37:59 [แก้ปัญหา] 1858722#1858722: *441 ว่าง: 0000562A9F69F340
22/10/2021 20:37:59 [แก้ปัญหา] 1858722#1858722: *438 http คำขออัพสตรีม: "/api/method/frappe.core.doctype.log_settings.log_settings.has_unseen_error_log?"
22/10/2021 20:37:59 [debug] 1858722#1858722: *438 http ส่วนหัวของกระบวนการอัปสตรีม
22/10/2021 20:37:59 [แก้ปัญหา] 1858722#1858722: *438 malloc: 0000562A9F712CB0:131072
22/10/2021 20:37:59 [แก้ปัญหา] 1858722#1858722: *438 recv: eof:0, avail:-1
22/10/2021 20:37:59 [แก้ปัญหา] 1858722#1858722: *438 recv: fd:9 678 จาก 131072
22/10/2021 20:37:59 [แก้ไขข้อบกพร่อง] 1858722#1858722: *438 http สถานะพร็อกซี 200 "200 ตกลง"
22/10/2021 20:37:59 [แก้ไขข้อบกพร่อง] 1858722#1858722: *438 ส่วนหัวของพร็อกซี http: "เซิร์ฟเวอร์: gunicorn"
... ส่วนหัวพร็อกซี http เพิ่มเติม ...
22/10/2021 20:37:59 [debug] 1858722#1858722: *438 http proxy header เสร็จแล้ว
22/10/2021 20:37:59 [debug] 1858722#1858722: *438 xslt filter header
22/10/2021 20:37:59 [แก้ไขข้อบกพร่อง] 1858722#1858722: *438 HTTP/1.1 200 ตกลง
เซิร์ฟเวอร์: nginx/1.18.0 (Ubuntu)
... การตอบสนอง HTTP

นี่คือการเจรจาที่ล้มเหลว:

22/10/2021 20:39:00 [แก้ปัญหา] 1858722#1858722: *446 ว่าง: 0000562A9F69F340
22/10/2021 20:39:00 [debug] 1858722#1858722: *446 http wait ตัวจัดการคำขอ
22/10/2021 20:39:00 [แก้ไขข้อบกพร่อง] 1858722#1858722: *446 malloc: 0000562A9F69F340:1024
22/10/2021 20:39:00 [แก้ปัญหา] 1858722#1858722: *446 SSL_read: 812
22/10/2021 20:39:00 [แก้ปัญหา] 1858722#1858722: *446 SSL_read: -1
22/10/2021 20:39:00 [แก้ปัญหา] 1858722#1858722: *446 SSL_get_error: 2
22/10/2021 20:39:00 [debug] 1858722#1858722: *446 การเชื่อมต่อที่ใช้ซ้ำได้: 0
22/10/2021 20:39:00 [แก้ปัญหา] 1858722#1858722: *446 posix_memalign: 0000562A9F70CEB0:4096 @16
22/10/2021 20:39:00 [debug] 1858722#1858722: *446 http บรรทัดคำขอกระบวนการ
22/10/2021 20:39:00 น. [ข้อมูล] 1858722#1858722: *446 ไคลเอนต์ส่งวิธีที่ไม่ถูกต้องขณะอ่านบรรทัดคำขอไคลเอนต์ ไคลเอ็นต์: 107.185.20.83 เซิร์ฟเวอร์: atlas-dev.ebs.llc คำขอ: "doctype= Error+Log&fields=%5B%22%60tabError+Log%60.%60name%60%22%2C%22%60tabError+Log%60.%60owner%60%22%2C%22%60tabError+Log%60.% 60creation%60%22%2C%22%60tabError+Log%60.%60modified%60%22%2C%22%60tabError+Log%60.%60modified_by%60%22%2C%22%60tabError+Log%60 %60_user_tags%60%22%2C%22%60tabError+Log%60.%60_comments%60%22%2C%22%60tabError+Log%60.%60_assign%60%22%2C%22%60tabError+Log%60 .%60_liked_by%60%22%2C%22%60tabError+Log%60.%60docstatus%60%22%2C%22%60tabError+Log%60.%60parent%60%22%2C%22%60tabError+Log% 60.%60parenttype%60%22%2C%22%60tabError+Log%60.%60parentfield%60%22%2C%22%60tabError+Log%60.%60idx%60%22%2C%22%60tabError+Log %60.%60method%60%22%2C%22%60tabError+Log%60.%60seen%60%22%5D&filters=%5B%5D&order_by=%60tabError+Log%60.%60modified%60+desc&start=0&page_length= 20&view=List&with_comment_count=true"
22/10/2021 20:39:00 [debug] 1858722#1858722: *446 http จบคำขอ: 400, "?" ก:1, ค:1
22/10/2021 20:39:00 [debug] 1858722#1858722: *446 ตัวจับเวลาเหตุการณ์ del: 9:337737968
22/10/2021 20:39:00 [แก้ไขข้อบกพร่อง] 1858722#1858722: *446 http การตอบกลับพิเศษ: 400, "?"
22/10/2021 20:39:00 [debug] 1858722#1858722: *446 http set ทิ้งเนื้อหา
22/10/2021 20:39:00 [debug] 1858722#1858722: *446 xslt filter header
22/10/2021 20:39:00 [debug] 1858722#1858722: *446 HTTP/1.1 400 คำขอไม่ถูกต้อง
เซิร์ฟเวอร์: nginx/1.18.0 (Ubuntu)
วันที่: ศุกร์ 22 ต.ค. 2564 20:39:00 GMT
ประเภทเนื้อหา: text/html
ความยาวเนื้อหา: 166
การเชื่อมต่อ: ปิด

จากสิ่งที่ฉันรู้เพียงเล็กน้อยเกี่ยวกับบันทึกการดีบัก nginx (เช่น ไม่มีอะไรเลย) สำหรับฉันแล้ว ดูเหมือนว่า nginx จะสลับเมธอด HTTP และ url สำหรับเนื้อหาในระหว่างการเจรจา เมื่อค้นหาเมธอด HTTP จะไม่มีอยู่อีกต่อไป และหยุดทำงาน

การกำหนดค่า SSL ของ Nginx

ข้อมูลเวอร์ชัน: nginx/1.18.0 (อูบุนตู), อูบุนตู 20.04 LTS ฉันใช้ค่าเริ่มต้น nginx.conf. ส่วน SSL ของเซิร์ฟเวอร์ conf มีลักษณะดังนี้:

ฟัง 443 ssl;

ชื่อเซิร์ฟเวอร์ [โฮสต์];

รูท /opt/erpnext/bench/sites;

proxy_buffer_size 128k;
proxy_buffers 4 256k;
proxy_busy_buffers_size 256k;

ssl_certificate /etc/letsencrypt/live/[โฮสต์]/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/[โฮสต์]/privkey.pem;
ssl_session_timeout 5 นาที;
ssl_session_cache ที่ใช้ร่วมกัน: SSL:10m;
ปิด ssl_session_tickets;
เปิด ssl_stapling;
เปิด ssl_stapling_verify;
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers EECDH+AESGCM:EDH+AESGCM;
ssl_ecdh_curve secp384r1;
เปิด ssl_prefer_server_ciphers;

มีการเปลี่ยนเส้นทาง SSL ที่ด้านล่างของไฟล์ และ nginx ได้รับการตั้งค่าให้เซิร์ฟเวอร์เว็บเซิร์ฟเวอร์ HTTP ที่ใช้ไฟล์แบนบนพอร์ต 8080 จากการกำหนดค่าอื่น

ฉันจะทราบได้อย่างไรว่าอะไรเป็นสาเหตุของปัญหา ฉันรู้ว่าคำขอถูกสร้างขึ้นอย่างถูกต้อง เนื่องจากคำขอที่เหมือนกันสำเร็จ... จนกว่าจะต้องมีการเจรจาการเชื่อมต่อ SSL ช่วย?

dave_thompson_085 avatar
jp flag
{voice='CrocodileDundee'} นั่นไม่ใช่การเจรจาใหม่ ใน TLS 1.2 และต่ำกว่า การเจรจาใหม่เป็นการจับมือกันใหม่โดยเฉพาะเพื่อเปลี่ยนพารามิเตอร์ความปลอดภัยในการเชื่อมต่อ _existing_ ฉันไม่คิดว่าเบราว์เซอร์ใดจะเริ่มต้นได้ แม้ว่าไคลเอนต์ประเภทอื่นจะทำได้หรืออย่างน้อยก็ทำได้ หลังจากช่องโหว่หลายรายการ (ซึ่งนำไปสู่ระบบจำนวนมากที่ห้ามหรือปิดกั้น) และแพตช์ (ดู rfc5746) ในการเจรจาใหม่ TLS1.3 ถูกลบออกทั้งหมด ...
dave_thompson_085 avatar
jp flag
... สิ่งที่คุณมีคือ OT1H (อีกครั้ง) โดยใช้การเชื่อมต่อ (และเซสชัน) ที่มีอยู่ หรือ OTOH สร้างการเชื่อมต่อใหม่ ซึ่งจะใช้การจับมือ/การเจรจาต่อรองใน 1.2 เสมอ หรือเพียงแค่การจับมือ (ไม่จำเป็นต้องแยกแยะเป็น เริ่มต้น) ใน 1.3; การจับมือกันนี้สามารถทำได้และสำหรับเบราว์เซอร์เกือบจะใช้ **การเริ่มต้นใหม่** ของ _session_ ก่อนหน้า (ใน 1.3 จริง ๆ แล้ว PSK มาจากเซสชันก่อนหน้าเพื่อส่งต่อความลับ) อย่างไรก็ตาม การแก้ไขชื่อไม่ได้ช่วยแก้ไขปัญหาของคุณ ขออภัย
jobu1342 avatar
cn flag
ดังนั้นที่คุณบอกว่ากำลังเจรจาความสัมพันธ์ใหม่ ไม่ใช่การเจรจาใหม่กับความสัมพันธ์เก่า ขออภัยที่ไม่ได้ใช้คำศัพท์ทางเทคนิค - อย่างที่คุณเดาว่าฉันไม่เข้าใจที่นี่ แน่นอน นั่นเป็นเหตุผลที่ฉันกำลังมองหาความช่วยเหลือ!
dave_thompson_085 avatar
jp flag
อย่างแน่นอน! การใช้คำศัพท์ทางเทคนิคไม่ได้ล้มเหลวมากนัก แต่บังเอิญ _ผิดทาง_ ในทางที่อาจทำให้คนที่คุณต้องการช่วยเหลือเข้าใจผิดได้ง่าย
jobu1342 avatar
cn flag
ฉันอัปเดตคำถาม - ขอบคุณที่ชี้แจง!
jobu1342 avatar
cn flag
ฉันเพิ่งทำการทดสอบข้ามเบราว์เซอร์และแม้แต่การทดสอบข้ามเครื่อง ไม่ใช่ทุกเบราว์เซอร์ที่ล้มเหลว แม้ว่าฉันจะไม่พบรูปแบบใดๆ เลย: FAIL: Google Chrome (Win10), Edge (Win10), Opera (Win10, ติดตั้งใหม่) ประสบความสำเร็จ: FireFox, Brave, Vivaldi, Google Chrome (Kubuntu 21.10), Google Chrome (Win10) เป็นที่น่าสังเกตว่า Google Chrome ทำงานหรือไม่ทำงานขึ้นอยู่กับคอมพิวเตอร์ การทดสอบของฉันไม่ครบถ้วนสมบูรณ์ แต่แนะนำจุดบกพร่องที่เกี่ยวข้องกับการติดตั้งในเครื่อง ฉันจะติดตั้ง Chrome ใหม่บนคอมพิวเตอร์เป้าหมายเพื่อดูว่าเริ่มทำงานหรือไม่
jobu1342 avatar
cn flag
ดังนั้น... ปรากฎว่าโปรแกรมป้องกันไวรัสของฉันกำลังทำงานแบบ sub-par man อยู่ตรงกลาง เมื่อฉันปิด AV ฉันไม่พบปัญหานี้เลย

โพสต์คำตอบ

คนส่วนใหญ่ไม่เข้าใจว่าการถามคำถามมากมายจะปลดล็อกการเรียนรู้และปรับปรุงความสัมพันธ์ระหว่างบุคคล ตัวอย่างเช่น ในการศึกษาของ Alison แม้ว่าผู้คนจะจำได้อย่างแม่นยำว่ามีคำถามกี่ข้อที่ถูกถามในการสนทนา แต่พวกเขาไม่เข้าใจความเชื่อมโยงระหว่างคำถามและความชอบ จากการศึกษาทั้ง 4 เรื่องที่ผู้เข้าร่วมมีส่วนร่วมในการสนทนาด้วยตนเองหรืออ่านบันทึกการสนทนาของผู้อื่น ผู้คนมักไม่ตระหนักว่าการถามคำถามจะมีอิทธิพลหรือมีอิทธิพลต่อระดับมิตรภาพระหว่างผู้สนทนา