Score:0

คำขอ HTTPS POST ล้มเหลวในการเชื่อมต่อกับความยาวเนื้อหา

ธง iq

แอปพลิเคชัน PHP โพสต์ข้อมูล XML ด้วย curl; ไม่มีอะไรแฟนซี ผลลัพธ์ดูเหมือน (c/p แต่เปลี่ยนตัวระบุและรหัสผ่าน):

โฮสต์: foreign.host.example
การอนุญาต: พื้นฐาน dGVzdDpnZWhlaW0=
User-Agent: ourhost HTTP-connector/1.0
ยอมรับ: */*
ผู้อ้างอิง: https://our.host.example/
ประเภทเนื้อหา: text/xml
ความยาวเนื้อหา: 9218
คาดหวัง: 100-ดำเนินการต่อ

[9218 ไบต์ของข้อมูล XML]

สิ่งนี้ทำบนโฮสต์ต้นทางสองสามตัว S1...Sn และโพสต์ไปยังโฮสต์เป้าหมายสองสามตัว T1...Tn หนึ่งสัปดาห์ที่ผ่านมาโฮสต์ S1 ได้รับการอัปเกรดจาก Debian/buster เป็น Debian/bullseye ซอฟต์แวร์ PHP ที่สร้างขึ้นได้รับการอัปเกรดเช่นกัน แต่ฉันไม่ทราบการเปลี่ยนแปลงใดๆ ในพื้นที่นี้ (และคำขอที่สร้างขึ้นมีลักษณะเหมือนกัน) ตั้งแต่การอัปเกรดนี้ โฮสต์เป้าหมายสองตัว (ไม่เกี่ยวข้องกัน) T1 และ T2 ปฏิเสธคำขอของเราด้วยรหัสตอบกลับ 400 โฮสต์เป้าหมายอื่นๆ ทั้งหมดทำงานได้ดี และ T1/T2 ทำงานได้ดี หากเชื่อมต่อจากโฮสต์ต้นทางอื่น (ที่มีระดับการแก้ไขเก่า)

ข้อโต้แย้ง: ความผิดอยู่ฝ่ายเรา แต่ที่ไหน?

หมายเหตุด้านข้าง: การวางส่วนหัวที่คาดไว้จะไม่เปลี่ยนแปลงอะไร

ข้อมูลเพิ่มเติม: แม้ว่า T1 จะตอบกลับด้วยรหัสตอบกลับ 400 เท่านั้น แต่ T2 จะสุภาพและมีข้อความแสดงสถานะ เช่น:

[our.ip.address]:60760 มีคำขอที่ไม่สมบูรณ์: ความยาวโดยประมาณคือ 3994 ไบต์ ได้รับ 3899 ไบต์

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

วิธีแก้ปัญหา: หากฉันระงับส่วนหัวของความยาวเนื้อหา การส่งข้อมูลจะทำงาน

สิ่งนี้ดีกว่าไม่มีอะไรเลย แต่ไม่น่าพอใจ - ฉันต้องการให้ปัญหาได้รับการแก้ไข ดังนั้นฉันจึงตรวจสอบตัวเลขสองครั้งและสามครั้งในส่วนหัวของความยาวเนื้อหา (เนื่องจากนี่เป็นสาเหตุเดียวที่เป็นไปได้ของข้อผิดพลาดที่ฉันนึกออก) ดูเหมือนว่าตกลงและใช้การคำนวณแบบเดียวกันกับโฮสต์ S2...Sn ซึ่งยังคงใช้งานได้ และ: ความยาวเนื้อหาบวกกับส่วนหัวโดยประมาณ (แน่นอนว่าจะแตกต่างกันเล็กน้อยเนื่องจากโฮสต์ การอนุญาต และผู้อ้างอิงรายอื่น) ไม่ใช่ความยาวโดยประมาณหรือความยาวที่ได้รับ แต่อยู่ตรงกลาง คำตอบที่ได้ให้ตัวเลขต่อไปนี้:

โดยประมาณ ได้รับ ความแตกต่าง
4322 4228 94
3972 3877 95
3994 3899 95
6928 6768 160

น่าเสียดายที่สิ่งนี้ไม่คงที่และไม่สั่นกระดิ่งใดๆ

ฉันตั้งค่าแท็กสองสามแท็กเพราะ Apache (2.4.52), OpenSSL (1.1.1k), curl (7.74.0) และ PHP (7.4.25) ได้รับการอัปเกรดพร้อมกับเซิร์ฟเวอร์ แม้ว่าฉันจะไม่เห็นผลกระทบที่เป็นไปได้ก็ตาม แต่ฉันไม่มีความคิดอื่น ดังนั้นฉันไม่ต้องการออกกฎนี้

ยินดีต้อนรับความคิดใด ๆ

jp flag
ใช้ `tcpdump` หรือพร็อกซีเพื่อบันทึกคำขอขาออกและยืนยันว่าคุณมี `ความยาวเนื้อหา' ที่ถูกต้องบนสาย
iq flag
สิ่งนี้ทำให้ฉันแทบคลั่ง: ด้วย mitmproxy ฉันสามารถดักฟังการโทรไปยังหนึ่งในไซต์ของเรา - ทุกอย่างเรียบร้อยดี ถ้าฉันพยายามติดต่อ T1 หรือ T2 คำขอ __hangs__ ในขณะที่ mitmproxy ทำการจับมือกับรีโมตโฮสต์ ฉันไม่เห็นส่วนหัวเลย ทันทีที่ฉันลดความยาวของเนื้อหา ทุกอย่างจะทำงานตามที่คาดไว้
iq flag
แต่ตอนนี้ฉันได้ดูที่เก็บข้อมูลแล้ว: ส่วนหัวความยาวเนื้อหาได้รับการตั้งค่าตั้งแต่กำเนิดของซอฟต์แวร์ในปี 2549 เป็นไปได้มากว่ามีบางอย่างเปลี่ยนแปลงในพื้นหลัง (cURL) เมื่อนานมาแล้ว ราวกับว่าฉันละเว้นไว้ cURL ตั้งค่า ส่วนหัวที่ถูกต้องอยู่แล้ว แม้ว่าฉันจะยังไม่เข้าใจว่าเกิดอะไรขึ้นที่นี่ แต่ฉันจะหยุดการสอบสวนเพิ่มเติม ณ จุดนี้

โพสต์คำตอบ

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