Java 웹앱이 .do 확장자를 사용하는 이유는 무엇입니까? 어디에서 왔습니까?

왜 그렇게 많은 Java 개발자가 웹 컨트롤러 (MVC) 리소스의 확장으로 ".do"를 사용하는지 궁금했습니다. 예 : http://example.com/register.do

Spring MVC 및 Struts 프로젝트에서 본 것처럼 특정 프레임 워크가 아닌 것 같습니다. 이 ".do"확장 연습은 어디에서 왔습니까? 확장이 아닌 대신 왜 그렇게 되었습니까? 이것에 대한 Java 세계 메모를 놓친 것 같습니다.

개인적으로 나는 연장을 선호하지 않습니다.

내가 아는 한이 컨벤션은 Struts1에 의해 전파되었습니다. 사용자 가이드는 다음과 같이 설명합니다.

5.4.2 ActionServlet 매핑 구성

참고 : 이 섹션의 자료는 Struts에만 국한되지 않습니다. 서블릿 매핑의 구성은 Java 서블릿 사양에 정의되어 있습니다. 이 섹션에서는 응용 프로그램을 구성하는 가장 일반적인 방법에 대해 설명합니다.

컨트롤러 서블릿에서 처리 할 URL을 정의하는 데는 접두사 일치 및 확장 일치라는 두 가지 일반적인 접근 방식이 있습니다. 각 접근 방식에 대한 적절한 매핑 항목은 아래에서 설명합니다.

접두사 일치는 특정 값으로 시작하는 (컨텍스트 경로 부분 뒤) 모든 URL이이 서블릿에 전달되기를 원한다는 것을 의미합니다. 이러한 항목은 다음과 같습니다.

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

이는 /logon앞서 설명한 경로 와 일치하는 요청 URI 가 다음과 같을 수 있음을 의미합니다 .

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

여기서 /myapplication응용 프로그램이 전개되고있는 상황에 맞는 경로입니다.

반면 확장 매핑은 URI가 마침표와 정의 된 문자 집합으로 끝나는 사실을 기반으로 요청 URI를 작업 서블릿과 일치시킵니다. 예를 들어, JSP 처리 서블릿 *.jsp은 요청 된 모든 JSP 페이지를 처리하기 위해 호출되도록 패턴에 매핑됩니다 . 확장 ( "무언가"를 의미 함) 을 사용하려면*.do 매핑 항목은 다음과 같습니다.

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

/logon앞에서 설명한 경로 와 일치하는 요청 URI 는 다음과 같습니다.

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

경고 - <servlet-mapping>컨트롤러 서블릿에 대해 둘 이상의 요소를 정의하면 프레임 워크가 올바르게 작동하지 않습니다 .

경고 -버전 1.1 이후 새 모듈 지원을 사용하는 경우 확장 매핑 만 지원된다는 점을 알고 있어야합니다.

그리고 저는이 규칙이 유지되었다고 생각합니다 (때로는 Struts1을 교체 한 후에도 URL을 변경하지 않기 위해, 때로는 사람들이 그것에 만족했기 때문에).

struts 서블릿에 URL을 전달하기 위해 web.xml의 * .do에 struts 서블릿을 매핑하는 것이 일반적이었습니다. 예를 들면 :

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

이것에 대한 관습을 제외하고는 정말 이유가 없습니다. 확장 기능을 사용하지 않는 경우 이미지 및 기타 정적 콘텐츠를 sevlet으로 보내지 않는 방식으로 처리하기 위해 약간의 마법을 수행해야합니다. 종종 이것은 프론 팅 웹 서버의로드 밸런서에서 수행됩니다.

보안 팁!

컨트롤러에 대해 비정상적인 확장을 사용하는 것이 좋습니다. 이렇게하면 침입자가 사이트에 대한 정보를 찾는 데 더 많은 시간을 할애해야합니다.

따라서 기본 확장을 변경하고 프레임 워크에서 손을 드러 낼 수있는 몇 가지 정적을 변경하면 MVC 프레임 워크를 완전히 알 수 없습니다.

확장을 변경 php하거나 aspx좋은 생각 일 수 있습니다.

실제로 이것은 난독 화에 의한 보안이지만 좋은 보안의 반대는 아닙니다. 이미 안전한 시스템 위에 모호한 보안을 계층화하면 도움이 될 수 있습니다. 난독 화에 의한 보안의 장단점과 둘 다 인터넷에서 사용할 수있는 경우가 있습니다.