เหตุใดเว็บแอป Java จึงใช้นามสกุล. do มันมาจากไหน?


114

ฉันสงสัยมาตลอดว่าทำไมนักพัฒนา Java จำนวนมากจึงใช้ ".do" เป็นส่วนขยายสำหรับทรัพยากรเว็บคอนโทรลเลอร์ (MVC) ตัวอย่าง: http://example.com/register.do

ดูเหมือนจะไม่ได้เป็นกรอบเฉพาะอย่างที่ฉันเคยเห็นในโครงการ Spring MVC และ Struts การฝึกขยาย ".do" นี้มาจากไหน เหตุใดจึงทำสิ่งนี้แทนที่จะไม่มีการขยาย ฉันรู้สึกว่าฉันพลาดบันทึกโลก Java ในเรื่องนี้

โดยส่วนตัวแล้วฉันไม่ชอบส่วนขยาย


4
หมายเหตุที่เป็นมิตรสำหรับผู้ที่ต้องการย้ายข้อมูลจาก ".do" และมี URL ที่จำง่าย ใช้เส้นทาง servlet แทนส่วนขยายเช่น / do / login จากนั้นใช้ Tuckey Filter URL การเขียนใหม่เพื่อสร้าง / do / login ==> / login
Adam Gent

จริงการเขียน URL ใหม่ (ไม่ว่าจะผ่าน mod_rewrite หรือตัวกรองของ Tuckey) จะทำเคล็ดลับ
Pascal Thivent

1
มันค่อนข้างงี่เง่าและไม่มีข้อแก้ตัวใด ๆ
ปฏิเสธไม่ได้

คำตอบ:


75

สำหรับความรู้ของฉันการประชุมนี้ได้รับการเผยแพร่โดย Struts1 คู่มือผู้ใช้วางไว้ดังนี้:

5.4.2 กำหนดค่าการแมป ActionServlet

หมายเหตุ: เนื้อหาในส่วนนี้ไม่เฉพาะสำหรับ Struts คอนฟิกูเรชันของการแม็พ servlet ถูกกำหนดไว้ใน Java Servlet Specification ส่วนนี้อธิบายถึงวิธีการทั่วไปในการกำหนดค่าแอปพลิเคชัน

มีสองวิธีทั่วไปในการกำหนด URL ที่จะประมวลผลโดย servlet ตัวควบคุม - การจับคู่คำนำหน้าและการจับคู่ส่วนขยาย รายการการทำแผนที่ที่เหมาะสมสำหรับแต่ละแนวทางจะอธิบายไว้ด้านล่าง

การจับคู่คำนำหน้าหมายความว่าคุณต้องการให้ URL ทั้งหมดที่เริ่มต้น (หลังส่วนพา ธ บริบท) ที่มีค่าเฉพาะถูกส่งไปยัง servlet นี้ รายการดังกล่าวอาจมีลักษณะดังนี้:

<servlet-mapping>
    <servlet-name>action</servlet-name>
    <url-pattern>/do/*</url-pattern>
</servlet-mapping>

ซึ่งหมายความว่า URI คำขอเพื่อให้ตรงกับ/logonเส้นทางที่อธิบายไว้ก่อนหน้านี้อาจมีลักษณะดังนี้:

http://www.mycompany.com/myapplication/do/logon

ที่/myapplicationเป็นเส้นทางบริบทตามที่แอพลิเคชันของคุณจะถูกนำไปใช้

ในทางกลับกันการแมปส่วนขยายจะจับคู่ URI คำขอกับ servlet การดำเนินการตามข้อเท็จจริงที่ว่า URI ลงท้ายด้วยจุดตามด้วยชุดอักขระที่กำหนด ตัวอย่างเช่น servlet การประมวลผล JSP ถูกแม็พกับ*.jspรูปแบบเพื่อให้ถูกเรียกให้ประมวลผลเพจ JSP ทุกเพจที่ร้องขอ ในการใช้*.do ส่วนขยาย (ซึ่งหมายถึง "ทำบางสิ่ง")รายการการจับคู่จะมีลักษณะดังนี้:

<servlet-mapping>
    <servlet-name>action</servlet-name>
    <url-pattern>*.do</url-pattern>
</servlet-mapping>

และ URI คำขอเพื่อให้ตรงกับ /logonเส้นทางที่อธิบายไว้ก่อนหน้านี้อาจมีลักษณะดังนี้:

http://www.mycompany.com/myapplication/logon.do

คำเตือน - เฟรมเวิร์กจะทำงานไม่ถูกต้องหากคุณกำหนด<servlet-mapping>องค์ประกอบมากกว่าหนึ่งรายการสำหรับ servlet คอนโทรลเลอร์

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

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


2
ฉันคิดว่ามันคือ Struts 1 นานมาแล้วฉันคงจะลืมไปแล้ว นั่นเป็นวันที่ไม่ค่อยดีนักสำหรับ Java Web Dev
Adam Gent

4
@Adam ตอนนั้น (~ 2001) ดีใจกับ Struts1 วันนี้ใช้มันคงทำให้ฉันร้องไห้
Pascal Thivent

5
ในปี 2544 เราโชคดีที่มี Struts 1!
Thorbjørn Ravn Andersen

2
ด้วย Struts 2 เราทุกคนมีความสุข!
Alireza Fattahi

9

เป็นเรื่องปกติที่จะแม็พ servlet struts ของคุณกับ * .do ใน web.xml เพื่อส่ง URL ไปยัง struts servlet ตัวอย่างเช่น:

<!-- Standard Action Servlet Mapping -->
<servlet-mapping>
    <servlet-name>action</servlet-name>
    <url-pattern>*.do</url-pattern>
</servlet-mapping>

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


2
ฉันไม่รู้ว่ามันเป็นเวทมนตร์ ทั้งหมดนี้มีการส่ง servlet หลักและอาจทำการเขียน URL ใหม่เพื่อหลีกเลี่ยงการมี / myservlet / นำหน้า ดูการเขียน URL ของ Tuckey ใหม่
Adam Gent

-2

เคล็ดลับความปลอดภัย!

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

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

เปลี่ยนนามสกุลเป็นphpหรือaspxอาจเป็นความคิดที่ดี

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


5
นั่นคือความปลอดภัยโดยความคลุมเครือ
TGO

นี่เป็นความสับสนจริงๆ
Brandon G

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

ตามค่าเริ่มต้นส่วนหัวการตอบกลับจะเพียงพอที่จะเข้าใจสิ่งต่างๆ
Kannan Ramamoorthy
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.