rack

Rack มอบอินเทอร์เฟซแบบโมดูลาร์ขั้นต่ำและปรับเปลี่ยนได้สำหรับการพัฒนาเว็บแอปพลิเคชันใน Ruby ด้วยการรวมคำขอและการตอบกลับ HTTP ด้วยวิธีที่ง่ายที่สุดเท่าที่จะเป็นไปได้ จะรวมและกลั่นบริดจ์ระหว่างเว็บเซิร์ฟเวอร์ เว็บเฟรมเวิร์ก และเว็บแอปพลิเคชันให้อยู่ในการเรียกเมธอดเดียว

รายละเอียดที่แน่นอนของสิ่งนี้อธิบายไว้ในข้อมูลจำเพาะของแร็ค ซึ่งแอปพลิเคชันของแร็คทั้งหมดควรปฏิบัติตาม

รองรับเวอร์ชัน

เวอร์ชัน	สนับสนุน
3.1.x	แก้ไขข้อผิดพลาดและแพตช์รักษาความปลอดภัย
3.0.x	แพทช์รักษาความปลอดภัยเท่านั้น
2.2.x	แพทช์รักษาความปลอดภัยเท่านั้น
<= 2.1.x	สิ้นสุดการสนับสนุน

โปรดดูนโยบายความปลอดภัยสำหรับข้อมูลเพิ่มเติม

ชั้น 3.1

นี่คือ Rack เวอร์ชันล่าสุด มันมีการแก้ไขข้อบกพร่องและแพตช์ความปลอดภัย โปรดตรวจสอบบันทึกการเปลี่ยนแปลงเพื่อดูข้อมูลโดยละเอียดเกี่ยวกับการเปลี่ยนแปลงเฉพาะ

แร็ค 3.0

แร็คเวอร์ชันนี้มีการเปลี่ยนแปลงที่สำคัญซึ่งมีรายละเอียดอยู่ในคู่มือการอัพเกรด ขอแนะนำให้อัปเกรดเป็น Rack 3 โดยเร็วที่สุดเพื่อรับฟีเจอร์และแพตช์ความปลอดภัยล่าสุด

ชั้น 2.2

Rack เวอร์ชันนี้ได้รับแพตช์รักษาความปลอดภัยเท่านั้น และควรพยายามย้ายไปยัง Rack 3

เริ่มต้นใน Ruby 3.4 การพึ่งพา base64 จะไม่เป็นอัญมณีเริ่มต้นอีกต่อไป และอาจทำให้เกิดคำเตือนหรือข้อผิดพลาดเกี่ยวกับ base64 หายไป เพื่อแก้ไขปัญหานี้ ให้เพิ่ม base64 เป็นการขึ้นต่อกันกับโปรเจ็กต์ของคุณ

การติดตั้ง

เพิ่มแร็คเจมลงในชุดแอปพลิเคชันของคุณ หรือปฏิบัติตามคำแนะนำที่ได้รับจากเฟรมเวิร์กเว็บที่รองรับ:

 # Install it generally:
$ gem install rack

# or, add it to your current application gemfile:
$ bundle add rack

หากคุณต้องการคุณสมบัติจาก Rack::Session หรือ bin/rackup โปรดเพิ่ม gem เหล่านั้นแยกกัน

$ gem install rack-session rackup

การใช้งาน

สร้างไฟล์ชื่อ config.ru โดยมีเนื้อหาดังต่อไปนี้:

 run do | env |
  [ 200 , { } , [ "Hello World" ] ]
end

รันสิ่งนี้โดยใช้แร็คอัพเจมหรือเว็บเซิร์ฟเวอร์อื่นที่รองรับ

$ gem install rackup
$ rackup

# In another shell:
$ curl http://localhost:9292
Hello World

เว็บเซิร์ฟเวอร์ที่รองรับ

แร็คได้รับการสนับสนุนโดยเซิร์ฟเวอร์ที่หลากหลาย รวมถึง:

• อากู๋
• เหยี่ยว
• ไอโอดีน
• หน่วย NGINX
• Phusion Passenger (ซึ่งเป็น mod_rack สำหรับ Apache และ nginx)
• โกย
• เสือพูมา
• บาง
• ยูนิคอร์น
• uWSGI
• Lamby (สำหรับ AWS Lambda)

คุณจะต้องศึกษาเอกสารประกอบของเซิร์ฟเวอร์เพื่อดูว่าฟีเจอร์และข้อจำกัดใดบ้างที่เซิร์ฟเวอร์อาจมี โดยทั่วไปแล้ว แอป Rack ที่ถูกต้องใดๆ จะทำงานเหมือนกันบนเซิร์ฟเวอร์เหล่านี้ทั้งหมด โดยไม่มีการเปลี่ยนแปลงใดๆ

แร็คอัพ

Rack จัดเตรียม gem แยกต่างหาก ซึ่งก็คือ rackup ซึ่งเป็นอินเทอร์เฟซทั่วไปสำหรับการรันแอปพลิเคชัน Rack บนเซิร์ฟเวอร์ที่รองรับ ซึ่งรวมถึง WEBRick , Puma , Falcon และอื่นๆ

กรอบเว็บที่รองรับ

เฟรมเวิร์กเหล่านี้และอื่นๆ อีกมากมายรองรับข้อกำหนดของแร็ค:

• แคมป์ปิ้ง
• ฮานามิ
• ราเมซ
• ปาดริโน
• โรดา
• รูบี้ออนเรลส์
• เหล้ารัม
• ซินาตร้า
• ยูโทเปีย
• WABuR

มิดเดิลแวร์ที่มีจำหน่ายซึ่งจัดส่งมาพร้อมกับแร็ค

ระหว่างเซิร์ฟเวอร์และเฟรมเวิร์ก แร็คสามารถปรับแต่งให้เหมาะกับความต้องการของแอปพลิเคชันของคุณโดยใช้มิดเดิลแวร์ ตัวแร็คเองมาพร้อมกับมิดเดิลแวร์ต่อไปนี้:

• Rack::CommonLogger สำหรับสร้างไฟล์บันทึกสไตล์ Apache
• Rack::ConditionalGet สำหรับการส่งคืนการตอบกลับ Not Modified เมื่อการตอบกลับไม่มีการเปลี่ยนแปลง
• Rack::Config เพื่อแก้ไขสภาพแวดล้อมก่อนประมวลผลคำขอ
• Rack::ContentLength สำหรับตั้งค่าส่วนหัว content-length เนื้อหาตามขนาดของร่างกาย
• Rack::ContentType สำหรับตั้งค่าส่วนหัว content-type เริ่มต้นสำหรับการตอบกลับ
• Rack::Deflater สำหรับบีบอัดการตอบกลับด้วย gzip
• Rack::ETag สำหรับการตั้งค่าส่วนหัว etag บนเนื้อหาที่สามารถบัฟเฟอร์ได้
• Rack::Events สำหรับการจัดเตรียม hooks อย่างง่ายเมื่อได้รับคำขอและเมื่อมีการส่งการตอบกลับ
• Rack::Files สำหรับให้บริการไฟล์คงที่
• Rack::Head สำหรับส่งคืนเนื้อหาว่างสำหรับคำขอ HEAD
• Rack::Lint สำหรับตรวจสอบความสอดคล้องกับข้อกำหนดของ Rack
• Rack::Lock สำหรับคำขอซีเรียลไลซ์โดยใช้ mutex
• Rack::MethodOverride สำหรับการแก้ไขวิธีการร้องขอตามพารามิเตอร์ที่ส่งมา
• Rack::Recursive สำหรับการรวมข้อมูลจากเส้นทางอื่นในแอปพลิเคชัน และสำหรับการดำเนินการเปลี่ยนเส้นทางภายใน
• Rack::Reloader สำหรับการโหลดไฟล์ซ้ำหากได้รับการแก้ไข
• Rack::Runtime สำหรับการรวมส่วนหัวการตอบกลับพร้อมเวลาที่ใช้ในการประมวลผลคำขอ
• Rack::Sendfile สำหรับการทำงานกับเว็บเซิร์ฟเวอร์ที่สามารถใช้การแสดงไฟล์ที่ปรับให้เหมาะสมสำหรับพาธของระบบไฟล์
• Rack::ShowException สำหรับการตรวจจับข้อยกเว้นที่ไม่สามารถจัดการได้ และนำเสนอด้วยวิธีที่ดีและเป็นประโยชน์ด้วย backtrace ที่คลิกได้
• Rack::ShowStatus สำหรับการใช้หน้าข้อผิดพลาดที่ดีสำหรับการตอบสนองข้อผิดพลาดของไคลเอ็นต์ที่ว่างเปล่า
• Rack::Static สำหรับการแสดงไฟล์คงที่ที่กำหนดค่าได้มากขึ้น
• Rack::TempfileReaper สำหรับการลบไฟล์ชั่วคราวที่สร้างขึ้นระหว่างการร้องขอ

ส่วนประกอบทั้งหมดเหล่านี้ใช้อินเทอร์เฟซเดียวกัน ซึ่งมีการอธิบายโดยละเอียดในข้อกำหนดเฉพาะของแร็ค ส่วนประกอบเสริมเหล่านี้สามารถใช้ได้ตามที่คุณต้องการ

อินเทอร์เฟซที่สะดวกสบาย

หากคุณต้องการพัฒนานอกกรอบงานที่มีอยู่ ปรับใช้กรอบงานของคุณเอง หรือพัฒนามิดเดิลแวร์ Rack มีตัวช่วยมากมายในการสร้างแอปพลิเคชัน Rack ได้อย่างรวดเร็วและโดยไม่ต้องทำสิ่งเดียวกันกับเว็บทั้งหมด:

• Rack::Request ซึ่งมีการแยกวิเคราะห์สตริงแบบสอบถามและการจัดการหลายส่วนด้วย
• Rack::Response เพื่อสร้างการตอบกลับ HTTP และการจัดการคุกกี้ที่สะดวก
• Rack::MockRequest และ Rack::MockResponse สำหรับการทดสอบแอปพลิเคชัน Rack ที่มีประสิทธิภาพและรวดเร็วโดยไม่ต้องไปกลับ HTTP จริง
• Rack::Cascade สำหรับการลองใช้แอปพลิเคชัน Rack เพิ่มเติม หากแอปพลิเคชันส่งคืนการตอบสนองที่ไม่พบหรือวิธีการไม่รองรับ
• Rack::Directory สำหรับให้บริการไฟล์ภายใต้ไดเร็กทอรีที่กำหนด พร้อมด้วยดัชนีไดเร็กทอรี
• Rack::MediaType สำหรับการแยกวิเคราะห์ส่วนหัวของประเภทเนื้อหา
• Rack::Mime สำหรับกำหนดประเภทเนื้อหาตามนามสกุลไฟล์
• Rack::RewindableInput สำหรับการสร้างอ็อบเจ็กต์ IO ใดๆ ที่สามารถกรอกลับได้ โดยใช้บัฟเฟอร์ไฟล์ชั่วคราว
• Rack::URLMap เพื่อกำหนดเส้นทางไปยังหลายแอปพลิเคชันภายในกระบวนการเดียวกัน

การกำหนดค่า

แร็คแสดงพารามิเตอร์การกำหนดค่าหลายตัวเพื่อควบคุมคุณสมบัติต่างๆ ของการนำไปใช้งาน

param_depth_limit

 Rack :: Utils . param_depth_limit = 32 # default

จำนวนการซ้อนสูงสุดที่อนุญาตในพารามิเตอร์ ตัวอย่างเช่น หากตั้งค่าเป็น 3 สตริงการสืบค้นนี้จะได้รับอนุญาต:

 ?a[b][c]=d

แต่สตริงการสืบค้นนี้จะไม่ได้รับอนุญาต:

 ?a[b][c][d]=e

การจำกัดความลึกจะป้องกันไม่ให้สแต็กโอเวอร์โฟลว์ที่เป็นไปได้เมื่อแยกวิเคราะห์พารามิเตอร์

multipart_file_limit

 Rack :: Utils . multipart_file_limit = 128 # default

จำนวนส่วนสูงสุดที่มีชื่อไฟล์ที่คำขอสามารถมีได้ การยอมรับชิ้นส่วนมากเกินไปอาจทำให้เซิร์ฟเวอร์ไม่มีตัวจัดการไฟล์

ค่าเริ่มต้นคือ 128 ซึ่งหมายความว่าคำขอเดียวไม่สามารถอัปโหลดได้มากกว่า 128 ไฟล์ในคราวเดียว ตั้งค่าเป็น 0 โดยไม่มีขีดจำกัด

นอกจากนี้ยังสามารถตั้งค่าผ่านตัวแปรสภาพแวดล้อม RACK_MULTIPART_FILE_LIMIT

(ซึ่งมีนามแฝงว่า multipart_part_limit และ RACK_MULTIPART_PART_LIMIT สำหรับความเข้ากันได้)

multipart_total_part_limit

จำนวนชิ้นส่วนทั้งหมดสูงสุดที่คำขอสามารถมีประเภทใดก็ได้ รวมถึงฟิลด์แบบฟอร์มทั้งแบบไฟล์และที่ไม่ใช่ไฟล์

ค่าเริ่มต้นคือ 4096 ซึ่งหมายความว่าคำขอเดียวไม่สามารถมีได้มากกว่า 4096 ส่วน

ตั้งค่าเป็น 0 โดยไม่มีขีดจำกัด

นอกจากนี้ยังสามารถตั้งค่าผ่านตัวแปรสภาพแวดล้อม RACK_MULTIPART_TOTAL_PART_LIMIT

บันทึกการเปลี่ยนแปลง

ดู CHANGELOG.md

มีส่วนร่วม

ดู CONTRIBUTING.md สำหรับรายละเอียดเฉพาะเกี่ยวกับวิธีการบริจาคให้กับ Rack

กรุณาโพสต์ข้อบกพร่อง คำแนะนำ และแพตช์ไปที่ปัญหา GitHub

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

ดูเพิ่มเติม

rackup

เครื่องมือที่มีประโยชน์สำหรับการรันแอปพลิเคชัน Rack จากบรรทัดคำสั่ง รวมถึง Rackup::Server (เดิมคือ Rack::Server ) สำหรับเซิร์ฟเวอร์การเขียนสคริปต์

• https://github.com/rack/rackup

rack-contrib

มิดเดิลแวร์ที่มีประโยชน์มากมายทำให้เกิดความต้องการโปรเจ็กต์ที่รวบรวมมิดเดิลแวร์ Rack ใหม่ rack-contrib มีส่วนประกอบเสริมที่หลากหลายสำหรับ Rack และง่ายต่อการสนับสนุนโมดูลใหม่

• https://github.com/rack/rack-contrib

rack-session

ให้การจัดการเซสชันที่สะดวกสำหรับ Rack

• https://github.com/rack/rack-session

ขอบคุณ

ทีมงาน Rack Core ประกอบด้วย

• แอรอน แพตเตอร์สัน มอบความรักอันอ่อนโยน
• ซามูเอล วิลเลียมส์ ไอโอควอติกส์
• เจเรมี อีแวนส์ เจเรมีแวนส์
• ไอลีน อูชิเทลล์ ไอลีนโค้ดส์
• แมทธิว เดรเปอร์ แมทธิว
• ราฟาเอล ฟรานซ่า ราฟาเอลฟรานกา

และศิษย์เก่าแร็ค

• ไรอัน โทเมโก้ rtomayko
• ไซตริน ได คินทรา ไซตริน
• ลีอาห์ นอยเคียร์เชน ลีอาห์นอยเคียร์เชน
• เจมส์ ทัคเกอร์ แร็กกี
• จอช พีค จอช
• โฮเซ่ วาลิม โจเซวาลิม
• ไมเคิล เฟลลิงเจอร์ แมนเวรู
• ซานติอาโก ปาสโตริโน สปาสโตริโน
• คอนสแตนติน ฮาส อาร์เคห์

ฉันอยากจะขอบคุณ:

• Adrian Madrid สำหรับผู้จัดการ LiteSpeed
• Christoffer Sawicki สำหรับอะแดปเตอร์ Rails ตัวแรกและ Rack::Deflater
• Tim Fletcher สำหรับรหัสตรวจสอบสิทธิ์ HTTP
• Luc Heinrich สำหรับเซสชันคุกกี้ ตัวจัดการไฟล์แบบคงที่ และการแก้ไขข้อบกพร่อง
• Armin Ronacher สำหรับโลโก้และเครื่องมือชั้นวาง
• อเล็กซ์ เบเรกสซาสซี, อเล็กซานเดอร์ คาห์น, อานิล วัดกูเล่, อาเรดริเดล, เบน อัลเพิร์ต, แดน คุบบ์, แดเนียล โรเอธลิสเบอร์เกอร์, แมตต์ ท็อดด์, ทอม โรบินสัน, ฟิล ฮาเกลเบิร์ก, เอส. เบรนท์ ฟอล์คเนอร์, บอสโก มิเลคิช, แดเนียล โรดริเกซ ทรอยติโน, เก็นกิ ทาคิอุชิ, เจฟฟรีย์ โกรเซนบัค, จูเลียน ซานเชซ, คามาล ฟาริซ มาห์ยุดดิน, มาซาโยชิ ทากาฮาชิ, แพทริค Aljordm, Mig, Kazuhiro Nishiyama, Jon Bardin, Konstantin Haase, Larry Siden, Matias Korhonen, Sam Ruby, Simon Chiang, Tim Connor, Timur Batyrshin และ Zach Brock สำหรับการแก้ไขข้อบกพร่องและการปรับปรุงอื่นๆ
• Eric Wong, Hongli Lai, Jeremy Kemper สำหรับการสนับสนุนอย่างต่อเนื่องและการปรับปรุง API
• Yehuda Katz และ Carl Lerche สำหรับการปรับโครงสร้างแร็คอัปใหม่
• Brian Candler สำหรับ Rack::ContentType
• Graham Batty เพื่อการโหลดตัวจัดการที่ดีขึ้น
• Stephen Bannasch สำหรับรายงานข้อผิดพลาดและเอกสารประกอบ
• Gary Wright สำหรับการนำเสนออินเทอร์เฟซ Rack::Response ที่ดีกว่า
• Jonathan Buch สำหรับการปรับปรุงเกี่ยวกับ Rack::Response
• Armin Röhrl สำหรับการติดตามจุดบกพร่องในตัวสร้างคุกกี้
• Alexander Kellett สำหรับการทดสอบอัญมณีและทบทวนประกาศ
• Marcus Rückert สำหรับความช่วยเหลือในการกำหนดค่าและการดีบัก lighttpd
• ทีม WSGI สำหรับงานที่ทำมาอย่างดีและมีเอกสารประกอบที่พวกเขาทำและได้ต่อยอด Rack ต่อไป
• ผู้รายงานข้อผิดพลาดและผู้มีส่วนร่วมในโปรแกรมแก้ไขทั้งหมดที่ไม่ได้กล่าวถึงข้างต้น

ใบอนุญาต

Rack ได้รับการเผยแพร่ภายใต้ใบอนุญาต MIT