content-type application/x-www-form-urlencoded는 POST방식으로만

2021/11/21

서론

오늘도 어김없이 영한님의 스프링 MVC 강의를 듣고 있었는데, html form 데이터를 body에 보낼 때는 post 방식 밖에 안된다는 말씀을 하시기에…
‘그럼 GET 방식도 안된다는건가?’ 라는 궁금증이 들어서 직접 확인해본 결과에 대해 작성한다.

본론

우선… 기본적으로 지금 필요한 GET방식과 POST방식의 차이점만을 다시 상기해보자면, GET방식은 데이터가 URL의 query string으로 들어간다는 것과,
POST방식은 데이터가 http message-body에 들어간다는 차이만 알아두면 될 것 같다. (다른 많은 차이가 있지만)

그렇기 때문에 우리가 html form 태그 에서 method attribute에 GET라고 작성한 후 데이터를 submit하면 데이터는 query string에 담겨 서버로 전송되고
POST라고 작성한 후 데이터를 submit하면 데이터는 message-body에 담겨서 서버로 전성되고 이 때 content-type은 application/x-www-form-urlencoded로 전송된다.

<!DOCTYPE html>
<html>
<head>
    <meta charset="UTF-8">
    <title>Title</title>
</head>
<body>
<form action="/request-param" method="post">
    username: <input type="text" name="username" />
    age:      <input type="text" name="age" />
    <button type="submit">전송</button>
</form>
</body>
</html>

content-type application/x-www-form-urlencoded는 POST방식으로만

그럼 method는 GET이면서 content-type은 application/x-www-form-urlencoded 일 경우엔 어떻게 될까?

postman으로 아래처럼 실행해본 결과 보는 것과 같이 400 error가 응답되며 요청에 실패하였다.

어째서 이런 일이 발생하였나를 코드 레벨에서 확인해보니…

tomcat의 Request class에 있는 parseParameters()라는 메서드에서 넘어온 데이터를 parsing 하는데,
이 때 http method가 post인지 확인하고 post가 아니라면 message-body의 데이터를 파싱 할 수 없게 되어 있는 것을 확인했다.

if( !getConnector().isParseBodyMethod(getMethod()) ) {
    success = true;
    return;
}

...


// 이 아래부턴 Connector.java

protected boolean isParseBodyMethod(String method) {
    return parseBodyMethodsSet.contains(method);
}

...

if (null == parseBodyMethodsSet) {
    setParseBodyMethods(getParseBodyMethods());
}

...

/**
 * Set list of HTTP methods which should allow body parameter
 * parsing. This defaults to <code>POST</code>.
 *
 * @param methods Comma separated list of HTTP method names
 */
public void setParseBodyMethods(String methods) {

    HashSet<String> methodSet = new HashSet<>();

    if (null != methods) {
        methodSet.addAll(Arrays.asList(methods.split("\\s*,\\s*")));
    }

    if (methodSet.contains("TRACE")) {
        throw new IllegalArgumentException(sm.getString("coyoteConnector.parseBodyMethodNoTrace"));
    }

    this.parseBodyMethods = methods;
    this.parseBodyMethodsSet = methodSet;
    setProperty("parseBodyMethods", methods);
}

...

/**
 * @return the HTTP methods which will support body parameters parsing
 */
public String getParseBodyMethods() {
    return this.parseBodyMethods;
}

...


/**
 * Comma-separated list of HTTP methods that will be parsed according
 * to POST-style rules for application/x-www-form-urlencoded request bodies.
 */
protected String parseBodyMethods = "POST";

위에 정리한 것 처럼

isParseBodyMethod()에서 지금 request의 method가 body를 파싱 할 수 있는 메서드 인지 확인하는데, 이 때 가능한 method들은 인스턴스 변수 parseBodyMethodsSet에 저장되어 있고,
인스턴스 변수 parseBodyMethodsSet는 setParseBodyMethods() 메서드에서 저장되고 있고~
parseBodyMethodsSet가 null인 경우에
setParseBodyMethods(getParseBodyMethods()) 메서드를 실행해서 이 때 method를 저장 시키는데,
getParseBodyMethods() 메서드를 호출하면
인스턴스변수 parseBodyMethods를 return 하는데
이 때 이 인스턴스 변수 parseBodyMethods에는 이미 “POST”로 method가 지정되어 있기 때문에
GET방식 일 경우에는 message-body를 파싱 할 수 있는 method가 아닌 것으로 처리 되므로~
파싱 할 수 없다는 에러 메시지를 출력하면서 프로세스가 끝이난다.

결론

생각해보면… content-type은 message-body이 어떤 형식의 데이터로 담겨 있는가를 알려주는 일종의 os의 파일 확장자같은 개념인데
당연히 get방식의 경우 message-body에 데이터가 담기는 것이 아니니 get방식으로 content-type만 application/x-www-form-urlencoded로 한다고 될 턱이 없는데
강의를 듣기만 했을 때는 왜 생각하지 못했는 지 모르겠다.. 머리가 나쁘면 몸이 고생이라더니 옛말에 틀린 말이 없다.

참고 사이트

댓글 공유

spring에서 request header를 parsing 하는 법

2021/11/15

서론

우선 사과의 말씀부터 올린다. 제목은 ‘spring에서~’ 지만 정확히는 tomcat에서 ~ 로 보는 것이 맞다.

인프런에서 김영한 님의 Spring MVC 강의를 보던 도중 … ‘http request를 정확히 어떠한 방식으로 파싱하고 있을까?’라는 궁금증이 생겨서 강의를 듣다가 말고 삽질을 한 내용을 기록해둔다.

본론

우선, 처음으로 궁금증을 해결하기 위해 들어가본 곳은 http request 요청을 받기 위한 HttpServletRequest interface의 tomcat 구현체인 RequestFacade class부터 시작했다.

이 중 getHeader 메서드에 대해 찾아보면,

Returns the value of the specified request header as a String.
If the request did not include a header of the specified name, this method returns null.
If there are multiple headers with the same name, this method returns the first head in the request.
The header name is case insensitive.
You can use this method with any request header.

RequestFacadeRequestFacade

라고 설명되어 있고… 이 때 코드에서 request의 header를 살펴보면

이미지와 같이 이미 header에 대한 정보들이 각각 저정되어 있는 걸 볼 수 있다.

필자가 궁금했던 것은 ‘이 request에 header는 언제 저장되는가?’ 였으므로
막연하게 ‘여기서 더 타고 올라가면 찾아 낼 수 있겠구나..’ 라고 안일한(?) 생각을 하고 안으로 더 들어가보았다.

타고타고 가다보니 …
http 1.1 header에 의한 요청이므로 Http11Processor의 service 메서드에서

// Don't parse headers for HTTP/0.9
if (!http09 && !inputBuffer.parseHeaders()) {
    // We've read part of the request, don't recycle it
    // instead associate it with the socket
    openSocket = true;
    readComplete = false;
    break;
}

처럼 작성되어 있는 코드를 발견했고, 여기에 있는 inputBuffer.parseHeaders() 을 보니
이름부터 여기서 http request에 대해 파싱을 할 것 같아 이 안으로 들어가보았다.

while (headerParsePos == HeaderParsePosition.HEADER_NAME) {

    // Read new bytes if needed
    if (byteBuffer.position() >= byteBuffer.limit()) {
        if (!fill(false)) { // parse header
            return HeaderParseStatus.NEED_MORE_DATA;
        }
    }

    int pos = byteBuffer.position();
    chr = byteBuffer.get();
    if (chr == Constants.COLON) {
        headerParsePos = HeaderParsePosition.HEADER_VALUE_START;
        headerData.headerValue = headers.addValue(byteBuffer.array(), headerData.start,
                pos - headerData.start);
        pos = byteBuffer.position();
        // Mark the current buffer position
        headerData.start = pos;
        headerData.realPos = pos;
        headerData.lastSignificantChar = pos;
        break;
    } else if (!HttpParser.isToken(chr)) {
        // Non-token characters are illegal in header names
        // Parsing continues so the error can be reported in context
        headerData.lastSignificantChar = pos;
        byteBuffer.position(byteBuffer.position() - 1);
        // skipLine() will handle the error
        return skipLine();
    }

    // chr is next byte of header name. Convert to lowercase.
    if ((chr >= Constants.A) && (chr <= Constants.Z)) {
        byteBuffer.put(pos, (byte) (chr - Constants.LC_OFFSET));
    }
}

들어가서보니 해당 코드처럼

현재 header data의 파싱된 위치가 key, value 형식의 데이터인 header의 name 부분 이라면 계속 반복하면서 버퍼에 저장하고 COLON(:) 을 만나게 되면,

1 2	headerData.headerValue = headers.addValue(byteBuffer.array(), headerData.start, pos - headerData.start);

코드가 실행되면서 아까 봤던 request의 MimeHeaders 타입인 header에 name으로 저장되고

value에도 위와 같은 방식으로 byte 단위로 이동하고 저장되면서 header에 value에 저장된다.

결론

서블릿이 http 통신을 위해 귀찮은 것들을 해준다는 것은 알고 있었지만
실제로 어떻게 하고 지에 대해서는 신경을 안 쓰고 있었는데 이렇게 강의를 듣다 보니 궁금해서 한번 확인해보았다.

만일 이 작업을 서블릿에서 대신 안해주지 않고 개발자가 개발할 때마다 해줘야한다고 생각하면…
머리가 어지러워지는 것 같아 이만 글을 줄인다…

참고 사이트

스프링 MVC 1편 - 백엔드 웹 개발 핵심 기술

댓글 공유

page 1 of 1

content-type application/x-www-form-urlencoded는 POST방식으로만

서론

본론

결론

참고 사이트

spring에서 request header를 parsing 하는 법

서론

본론

결론

참고 사이트

Junggu Ji