2010-06-09 3 views
4

나는 classifieds 웹 사이트가있다.여기에 POST 방법을 사용하지 않는 이유는 무엇입니까?

메인 페이지 (색인)에는 사용자가 입력 할 수도 있고 기입하지 않을 수도있는 여러 양식 필드가있어 분류 광고의 세부 검색을 지정합니다.

예 :

가 query_sql.php에서
<form action='query_sql.php' method='post'> 

I는 다음과 같이 변수를 페치 :이어서

category=$_POST['category']; 
    etc etc... 

Category: Cars 
    Price from: 3000 
    Price to: 10000 
    Color: Red 
    Area: California 

폼 '액션은 PHP 페이지로 설정 쿼리 MySql :

$query="SELECT........WHERE category='$category' etc etc.... 
    $results = mysql_query($query); 

그런 다음 결과 집합에 따라 동적으로 채워지는 표를 만들어 사용자에게 쿼리 결과를 표시하기 만하면됩니다.

하지만, 내 이전 QI에서 골 파편의 답변에 따라 여기에 POST를 사용하지 않아야합니다 : How to hide URL from users when submitting this form?

내가 게시물을 사용하는 이유입니다 단순히 "한 페이지 워드 문서"긴 숨 깁니다 브라우저의 주소 표시 줄에있는 URL.

매우 혼란 스럽습니다. POST를 사용해도 되나요? 지금 GET 또는 POST를 사용하여 ... 그리고 링크 된 질문에 BTW, ... 프로덕션 서버에 이미

때 그것은 잘 작동

모두, 나는 URL 보이지 않게하기 위해 언급되지 않았다 (또는 숨기기) 난 그냥 너무 (mod_rewrite 함께 성취했습니다) 더 잘 보이고 싶었어요.

업데이트 : GET을 사용하는 경우

, 다음 어떻게해야 URL이 더 나은 (아름다운)를 찾고 계십니까? 확인이 이전 Q 아웃 :

How to make this very long url appear short?

+0

매개 변수화 된 쿼리를 사용하거나 적어도 입력 문자열을 이스케이프 처리해야합니다. 표시된 코드로 데이터베이스를 손상시키는 요청을 작성하는 것은 간단합니다. – tvanfosson

+0

짧은 URL (SEO 제외)을 사용하는 또 다른 방법은 POST를 수행하고 DB 테이블에 검색 필터를 저장 한 다음 삽입 된 레코드의 ID를 가져 와서 search.php와 같은 페이지로 리디렉션하는 것입니다. searchid = 123456 검색. 이렇게하면 많은 매개 변수를 사용하면서 짧은 URL을 가질 수 있습니다. 검색 할 필드를 변경하면 테이블의 구조를 조심하십시오. – Keeper

+0

** 긴 URL에 무엇이 잘못 되었나요 **? –

답변

12
  • 검색 엔진이 아닌 인덱스 결과
  • 사람들은 즐겨 찾기 검색
  • 사람들은 그들의 검색에 대한 링크를 보낼 수없는 것입니다 그들의 친구
  • 사람들은 자신의 웹 페이지에서 결과 페이지에 연결할 수 없습니다.
  • 일부 사람들은 이동할 수 없습니다. 무서운 것을받지 않고 페이지로 돌아 가기 "하고 싶습니까? 양식을 다시 제출 하시겠습니까? " 내가 GET을 사용하는 경우

, 다음 어떻게 URL이 더 나은 (아름다운)보고해야한다?

하지 않아야합니다. 그건 중요하지 않아. 양식이 제출 된 URL을 알아 채는 사용자의 수는 작으며 관심있는 사람의 수는 훨씬 적습니다.

+0

내 업데이트 pls를 확인하십시오 –

+0

@Camran re your update, 나는 그것이 다른 질문이라고 말하고 싶습니다. –

+0

하지만 검색 엔진이 POST URL을 무시한다고 말하면 q = 938 & b = alskda & c = 835983jdla & d = 9284 등 길고 못생긴 URL도 무시합니다. 그래서 내 경우에는이 문제가 중요하지 않다고 생각합니다. "폼을 다시 제출 하시겠습니까?"라는 메시지가 나오면 싫어하기 때문에 새로 고침 버튼 또는 뒤로 버튼이 테스트되었습니다. –

1

POST를 통한 GET 사용의 배경은 GET을 사용하면 주소 표시 줄에서 수정하고 책갈피를 지정하고 전달할 수있는 검색 URL을 사용할 수 있다는 것입니다.

기술적으로 두 가지 방법은 모두 이며 기본적으로 상호 교환 가능합니다. 이러한 측면을 처리 할 필요가없고 한 페이지에서 다음 페이지로 데이터를 전달할 경우에만 을 교환 할 수 있습니다.

GET과 POST의 큰 차이점 중 하나는 GET 매개 변수가 1-2 킬로바이트 크기를 초과하지 않아야한다는 것입니다. POST 요청의 크기 제한은 일반적으로 수십 메가 바이트입니다.

+0

하나의 큰 차이점이 있습니다 : GET 요청은 멱등 원 (표준 당)으로되어 있습니다. 항상 존경받는 것은 아닙니다 ... (예 : "이메일 확인을위한 링크를 클릭하십시오") – Artefacto

+0

@Arte 흥미로 우며, 몰랐습니다! 그리고 예, 그것은 종종 존중하지 않습니다 ... –

+0

-1 그들은 서로 교환 할 수 있음을 제안합니다 - RTFM Pekka! – symcbean

0

우선 입력 내용은 mysql_real_escape_string을 사용하여 위생적으로 처리해야합니다. POST 대 GET는 것을 제외하고 실질적으로 동일합니다 : 당신은 GET으로 페이지

  • 를 즐겨 찾기에 추가 할 수는 파일을 게시 할 수 없습니다 및 쿼리 문자열의 길이 제한이

    POST와

    페이지가 서버 측 (예 : DB 업데이트)을 수정 한 다음 다른 페이지로 리디렉션하는 경우에만 POST를 사용합니다.

  • +0

    GET 요청에는 제한이 있습니다. http://stackoverflow.com/questions/266322/http-uri-get-limit – Alsciende

    1
    당신은 아마 입력이 직접 SQL 문을 조작되는 것처럼 보이는 SQL 주입 공격을 완화하기 위해 사용자 입력에 대한 몇 가지 신원 조사를 수행 할

    0

    데이빗도 워드의 대답 주소 점의 대부분을 - 그러나 큰 일 그는 캐시 가능성 문제를 놓치고 있습니다.

    POST 및 GET에는 매우 구체적인 의미가 있습니다. POST는 요청이 시스템의 데이터를 변경하고 GET은 변경하지 않음을 의미합니다. 따라서 POST에 대한 응답을 캐시해서는 안됩니다. 그러나 GET에 대한 응답은 전송 된 헤더에 따라 캐시 될 수 있습니다.

    NB 콘텐츠는 브라우저에 캐시되지 않습니다.

    +0

    적절한 HTTP 응답 헤더가 전송되면 POST 요청을 캐시 할 수 있습니다. – Quentin

    1

    는 어느 판독 전용 또는 데이터에 어떤 부작용이없는 요청을 표기 GET C.합니다 (HTTP documentation에서 설명한 바와 같이, 즉 그들은 idempotent이어야 함). 원하는 결과가 반환 될 영향을주지 않고 원하는만큼 GET 요청을 제출할 수 있어야합니다. 물론 다른 결과가 변경 될 수 있기 때문에 항상 같은 결과를 얻을 수는 없겠지만 GET 요청은 데이터 자체를 변경해서는 안됩니다. 당신은, 당신은 단지 그들이 당신을 제공하고 일부 매개 변수를 기반으로 사용자에게 데이터를 제공하고 검색 할 때 출력에 영향을 미칠 것이다 당신의 시스템의 모든 데이터를 변경하지 않아야하기 때문에

    그래서 검색이 범주에 온다 .

    물론 통계 (코멘트에 언급 된 바와 같이)와 같이 항상 업데이트되기를 원하는 데이터는 GET과 관련하여 응답에 영향을 미치지 않으므로 단지 레코드 만 유지하면됩니다. 모든 요청 등

    파괴적인 행동이 수행 될 때 사용되어야합니다 (파괴적으로, 데이터가 변경되었을 때 .. 단지 삭제가 아니라는 의미입니다). 그래서 당신은 POST 요청을 다시 제출하려면 브라우저가 보통이 아닌 GET에 대한, 메시지를 표시합니다 이유는 등

    , 삭제, 추가, 업데이트.POST가 데이터가 변경 될 때 사용되기 때문입니다.

    또한 일부 브라우저는 페이지의 링크에서 페이지를 미리 가져올 수 있습니다 (링크를 클릭하면 속도가 떨어지는 것처럼 보입니다). GET 동작이 파괴적인 작업 (예 : 레코드 삭제)을 수행하면 실수로 링크가 연결된 페이지를 방문하여 실수로 트리거 될 수 있습니다.

    "지저분한"URL이 염려된다면 mod_rewrite과 같은 URL을 사용하면보다 인간 친화적 인 URL을 만들 수 있습니다. 따라서 "http://yoursite.com/search/cars/red"은 예를 들어 "http://yoursite.com/search.php?category=cars&color=red"에 매핑 될 수 있습니다.

    +0

    검색을 통해 시스템의 데이터가 변경 될 가능성이 있습니다. Stastistics 중요합니다. 또한 작업이 시스템을 변경하지 않기 때문에 멱등 원이라고 부를 수 없습니다. 멱등 원은 동일한 입력에 대해 동일한 결과를 얻습니다. 시스템을 변경하지 않아도 검색이 수행되지 않을 수 있습니다. OTOH 검색에 GET을 사용해야한다는 데 동의합니다 –

    +0

    멱수가 반드시 동일한 입력이 같은 결과라는 것을 의미하지는 않습니다. 즉, 동일한 입력을 여러 번 입력하면 결과에 부작용이 발생하지 않습니다 (그러나 다른 것이 데이터를 업데이트 한 경우 결과가 달라질 수 있음). 따라서 통계는 출력에 영향을 미치지 않으므로 괜찮 으면 어쨌든 모든 요청에 ​​대해 통계를 수집해야합니다. 내가 좀 더 혼란스럽게 만들었 을까 두려워하기는하지만 나는이 답변을 조금 더 명확하게하기 위해 나의 대답을 업데이트했다. :) –

    0

    친숙하지 않은 URL에 관심이있는 것처럼 들립니다. 즉, 사이트/애플리케이션 전체에서 친숙한 URL을 원합니다. 그렇다면 시나리오에서 POST를 계속 사용할 수 있지만 POST 후에는 리디렉션을 수행하십시오. 리디렉션 이후 게시물을 수행하면 검색 결과를 렌더링하는 리디렉션 된 URL을 친숙하고 짧게 만들 수 있습니다. POST를 사용하여 요청에서 더 많은 매개 변수를 서버에 전달하고 서버에 관련된 긴 쿼리 문자열을 피할 수 있습니다 URL을 얻으십시오.

    GET (또는 POST)를 통해 양식을 제출 한 후 서버 측 양식의 내용을 읽어

    더, 후 - 후 - 재 http://www.theserverside.com/news/1365146/Redirect-After-Post

    0

    당신이 생각나요이 문서를 체크 아웃 내용 (url 또는 post 데이터에서) 좋은 URL을 만든 다음 해당 url에 301 리디렉션합니다.

    URL을 완벽하게 제어 할 수 있습니다 (예 : 브라우저/양식이 아닌 URL의 모양). GET을 사용하면 모든 이점을 누릴 수 있습니다. 북마크 가능, 링크 가능, 뒤로 버튼 친숙성 등

    관련 문제