പുതിയ HTTP QUERY മെത്തേഡ്: ബോഡിയുള്ള ഒരു GET റെക്വസ്റ്റ്

1996 മുതൽ വെബിന്റെ നട്ടെല്ലാണ് HTTP. ഏകദേശം മൂന്ന് പതിറ്റാണ്ടിനിടയിൽ, പ്രധാന മെത്തേഡുകളായ — GET, POST, PUT, DELETE, PATCH — കാര്യമായി മാറിയിട്ടില്ല. ഡെവലപ്പർമാർ അവയ്ക്ക് മുകളിൽ REST APIs-ന്റെ വലിയ സാമ്രാജ്യങ്ങൾ തന്നെ കെട്ടിപ്പടുത്തു. ഭൂരിഭാഗം ഉപയോഗ കേസുകളിലും, അവ നന്നായി പ്രവർത്തിക്കുന്നു.

എന്നാൽ അവിടെയൊരു വിടവുണ്ടായിരുന്നു. എല്ലാ API ഡെവലപ്പർമാരും എപ്പോഴെങ്കിലും നേരിട്ടിട്ടുള്ള ഘടനാപരവും അസ്വസ്ഥതയുണ്ടാക്കുന്നതും ചിലപ്പോൾ അപകടകരവുമായ ഒരു വിടവ്: ഡാറ്റ തിരയേണ്ടിവരുകയും ആ തിരച്ചിൽ സങ്കീർണ്ണമായിരിക്കുകയും ചെയ്യുമ്പോൾ നിങ്ങൾ എന്താണ് ചെയ്യുന്നത്?

2026 ജൂലൈ 17-ന്, ആ വിടവിന് ഒടുവിൽ ഒരു ഔദ്യോഗിക ഉത്തരം ലഭിച്ചു. QUERY HTTP മെത്തേഡ് — 2026 ജൂൺ 15-ന് സ്റ്റാൻഡേർഡൈസ് ചെയ്യപ്പെടുകയും RFC 9148-ൽ ഔദ്യോഗികമായി നിർവ്വചിക്കപ്പെടുകയും ചെയ്തത് — വളരെക്കാലത്തിന് ശേഷമുള്ള HTTP മെത്തേഡ് കുടുംബത്തിലെ ആദ്യത്തെ പുതിയ കൂട്ടിച്ചേർക്കലാണ്. കൂടാതെ GET, POST എന്നിവ ഒരിക്കലും വൃത്തിയായി കൈകാര്യം ചെയ്യാത്ത ഒരു യഥാർത്ഥ പ്രശ്നം ഇത് പരിഹരിക്കുന്നു.

പ്രശ്നം: GET-ന് സങ്കീർണ്ണമായ തിരച്ചിലുകൾ കൈകാര്യം ചെയ്യാൻ കഴിയില്ല

ഡാറ്റ ലഭ്യമാക്കുന്നതിൽ ഏറ്റവും കൂടുതൽ ഉപയോഗിക്കുന്ന ഒന്നാണ് GET. നിങ്ങൾ ഒരു URL തുറക്കുന്നു, സെർവർ നിങ്ങൾക്ക് ഡാറ്റ നൽകുന്നു. ലളിതവും, വ്യക്തവും, കാഷെ ചെയ്യാവുന്നതും. ലളിതമായ തിരച്ചിലുകൾക്ക് — "give me user 42" അല്ലെങ്കിൽ "list all published posts" — GET വളരെ അനുയോജ്യമാണ്.

എന്നാൽ ആധുനിക ആപ്ലിക്കേഷനുകൾ എപ്പോഴും ലളിതമായ ചോദ്യങ്ങളല്ല ചോദിക്കുന്നത്.

നിങ്ങൾ ഒരു അനലിറ്റിക്സ് ഡാഷ്‌ബോർഡ് നിർമ്മിക്കുകയാണെന്ന് സങ്കൽപ്പിക്കുക. ഒരു ഉപയോക്താവിന് പന്ത്രണ്ട് വ്യത്യസ്ത പാരാമീറ്ററുകൾ അനുസരിച്ച് ഫിൽട്ടർ ചെയ്യണം: തീയതി പരിധികൾ, നെസ്റ്റഡ് ഭൂമിശാസ്ത്രപരമായ പ്രദേശങ്ങൾ, നിർദ്ദിഷ്ട ഉൽപ്പന്ന വിഭാഗങ്ങൾ, ബൂളിയൻ ലോജിക്കുള്ള ഉപയോക്തൃ വിഭാഗങ്ങൾ, കൂടാതെ ഒരു ഫ്രീ-ടെക്സ്റ്റ് തിരച്ചിൽ ചോദ്യവും. ആ ഫിൽട്ടർ സെറ്റ് എളുപ്പത്തിൽ 1,000 ബൈറ്റിൽ കവിയാം.

ഇവിടെയാണ് GET പരാജയപ്പെടുന്നത്. ഒരു GET request-ലെ എല്ലാം URL-ലാണ് ഉൾപ്പെടുന്നത്. URL-കൾക്ക് പ്രായോഗികമായ നീള പരിധികളുമുണ്ട്. ബ്രൗസറുകൾ അവ പരിമിതപ്പെടുത്തുന്നു, പ്രോക്സികൾ വെട്ടിച്ചുരുക്കുന്നു, സെർവറുകൾ നിരസിക്കുന്നു. സെർവറുകൾ കുറഞ്ഞത് 8,000 ബൈറ്റുകളെങ്കിലും കൈകാര്യം ചെയ്യണമെന്ന് RFC 2616 ശുപാർശ ചെയ്യുന്നു, എന്നാൽ പല പ്രായോഗിക സിസ്റ്റങ്ങളും അതിനുമുമ്പുതന്നെ പരാജയപ്പെടുന്നു.

പോരാത്തതിന്, ആ URL പാരാമീറ്ററുകൾ എല്ലായിടത്തും ലോഗ് ചെയ്യപ്പെടുന്നു. ബ്രൗസർ ഹിസ്റ്ററി പൂർണ്ണമായ URL റെക്കോർഡ് ചെയ്യുന്നു. പ്രോക്സി സെർവറുകൾ അത് കാഷെ ചെയ്യുന്നു. സെർവർ ആക്സസ് ലോഗുകൾ അത് സൂക്ഷിക്കുന്നു. നിങ്ങളുടെ തിരച്ചിലിൽ സെൻസിറ്റീവായ ഡാറ്റ ഉൾപ്പെട്ടിട്ടുണ്ടെങ്കിൽ — ഒരു പേഷ്യന്റ് ID, സോഷ്യൽ സെക്യൂരിറ്റി നമ്പർ ഫ്രാഗ്മെന്റ്, അല്ലെങ്കിൽ ആന്തരിക അക്കൗണ്ട് റഫറൻസ് — ആ വിവരങ്ങൾ ഇപ്പോൾ നിങ്ങൾ നിയന്ത്രിക്കാത്ത ഒന്നിലധികം സിസ്റ്റങ്ങളിൽ പ്ലെയിൻ ടെക്സ്റ്റായി കിടക്കുന്നു.

അതൊരു സൈദ്ധാന്തിക ആശങ്കയല്ല. അതൊരു യഥാർത്ഥ കംപ്ലയൻസ് തലവേദനയാണ്.

പ്രശ്നം: POST ഒരു കള്ളമാണ്

അതിനാൽ ഡെവലപ്പർമാർ എപ്പോഴും ചെയ്യുന്നതുതന്നെ ചെയ്യുന്നു — അവർ ഈ പരിമിതിയെ മറികടക്കാൻ വഴി കണ്ടെത്തുന്നു. "POST മാത്രം ഉപയോഗിക്കൂ," കോഡ് റിവ്യൂവിൽ ആരെങ്കിലും പറയുന്നു. "നിങ്ങൾക്ക് ഒരു POST request-ൽ ഒരു JSON body ഉൾപ്പെടുത്താം, ആ body URL-ൽ അവസാനിക്കുകയുമില്ല."

സാങ്കേതികമായി ശരിയാണ്. എന്നാൽ അർത്ഥപരമായി തെറ്റാണ്.

ഡാറ്റയിൽ മാറ്റം വരുത്താനാണ് POST രൂപകൽപ്പന ചെയ്തിരിക്കുന്നത്. ഇത് സെർവറിനോട് പറയുന്നു: "ഞാൻ നിങ്ങൾക്ക് എന്തോ അയയ്ക്കുന്നു — ഒരു റിസോഴ്സ് സൃഷ്ടിക്കുക, ഒരു പ്രക്രിയ ട്രിഗർ ചെയ്യുക, അല്ലെങ്കിൽ ഏതെങ്കിലും സ്റ്റേറ്റ് മാറ്റുക." HTTP സ്പെസിഫിക്കേഷനുകൾ പറയുന്നത് അതാണ്. വെബ് ആപ്ലിക്കേഷൻ ഫയർവാളുകൾ പ്രതീക്ഷിക്കുന്നത് അതാണ്. സെർവർ ഫ്രെയിംവർക്കുകൾ കരുതുന്നതും അതാണ്.

ഡാറ്റ തിരയാൻ നിങ്ങൾ POST ഉപയോഗിക്കുമ്പോൾ, നിങ്ങൾ സിസ്റ്റത്തിന്റെ ഓരോ ലെയറിനോടും കള്ളം പറയുകയാണ്.

ഇത് കേവലം തത്വചിന്താപരമായ ശുദ്ധിയല്ല. ഇതിന് യഥാർത്ഥ പ്രത്യാഘാതങ്ങളുണ്ട്:

• കാഷിംഗ് തകരാറിലാകുന്നു. ഭൂരിഭാഗം HTTP കാഷെകളും — CDNs, റിവേഴ്സ് പ്രോക്സികൾ, ബ്രൗസർ കാഷെകൾ — ഡിഫോൾട്ടായി POST റെസ്‌പോൺസുകൾ കാഷെ ചെയ്യില്ല, കാരണം POST എന്നാൽ ഓരോ തവണയും റെസ്‌പോൺസ് വ്യത്യസ്തമാകാം എന്ന് കരുതപ്പെടുന്നു (സെർവർ സ്റ്റേറ്റ് മാറിയതിനാൽ).
• യാദൃശ്ചികമായ പാർശ്വഫലങ്ങൾ. ചില സെർവർ ഫ്രെയിംവർക്കുകളും മിഡിൽവെയറുകളും POST-നെ വ്യത്യസ്തമായി കൈകാര്യം ചെയ്യുന്നു. നിങ്ങളുടെ "search" എൻഡ്പോയിന്റ് ഒരു "create" എൻഡ്പോയിന്റ് പോലെ കാണപ്പെടുന്നതിനാൽ മാത്രം അവ ഓഡിറ്റ് ലോഗുകളിൽ എഴുതുകയോ, വെബ്ഹൂക്കുകൾ ട്രിഗർ ചെയ്യുകയോ, അല്ലെങ്കിൽ വ്യത്യസ്ത റേറ്റ്-ലിമിറ്റിംഗ് നിയമങ്ങൾ ബാധകമാക്കുകയോ ചെയ്തേക്കാം.
• CSRF സാധ്യത വർദ്ധിക്കുന്നു. POST എൻഡ്പോയിന്റുകൾക്ക് വ്യത്യസ്തമായ ക്രോസ്-ഒറിജിൻ സെക്യൂരിറ്റി സെമാന്റിക്സ് ആണുള്ളത്. POST ഉപയോഗിക്കുന്ന ഒരു സെർച്ച് എൻഡ്പോയിന്റിന് ഇപ്പോൾ ഒരു GET എൻഡ്പോയിന്റിന് ആവശ്യമില്ലാത്ത CSRF സംരക്ഷണം ആവശ്യമായി വരുന്നു.
• റീട്രൈകൾ അപകടകരമാകുന്നു. ഒരു request ടൈംഔട്ട് ആയാൽ, ക്ലയന്റുകൾക്ക് സുരക്ഷിതമായി GET വീണ്ടും ശ്രമിക്കാം (ഇത് idempotent ആണ്). ഒരു POST വീണ്ടും ശ്രമിക്കുന്നത് ഡ്യൂപ്ലിക്കേറ്റ് റെക്കോർഡുകൾ സൃഷ്ടിച്ചേക്കാം — നിങ്ങളുടെ "search" എൻഡ്പോയിന്റ് ഒന്നും സൃഷ്ടിക്കാൻ പാടില്ലാത്തതുമാണ്.

ഈ പൊരുത്തക്കേട് വർഷങ്ങളായി ബഗ്ഗുകൾക്കും, സെക്യൂരിറ്റി പ്രശ്നങ്ങൾക്കും, ആർക്കിടെക്ചറൽ ബുദ്ധിമുട്ടുകൾക്കും കാരണമായിട്ടുണ്ട്. GraphQL, അതിന്റെ എല്ലാ മേന്മകൾക്കിടയിലും, ഇത് കൂടുതൽ സാധാരണമാക്കി — മിക്ക GraphQL നടപ്പിലാക്കലുകളും ക്വറികൾ POST request ആയി അയയ്ക്കുന്നു, അതായത് ഒരു GraphQL API-യിലെ ഓരോ റീഡ് ഓപ്പറേഷനും ഒരു റൈറ്റ് ഓപ്പറേഷന്റെ സെമാന്റിക് ബാധ്യത പേറുന്നു.

QUERY വരുന്നു: ആവശ്യത്തിന് അനുയോജ്യമായ ഉപകരണം

QUERY മെത്തേഡ് പേര് സൂചിപ്പിക്കുന്നത് പോലെ തന്നെയാണ്: ഒരു ബോഡിയെ പിന്തുണയ്ക്കുന്ന GET request.

ഇതിനെ വ്യത്യസ്തമാക്കുന്നത് ഇതാ:

ഇത് സുരക്ഷിതവും റീഡ്-ഓൺലിയുമാണ്. QUERY മെത്തേഡ് ഒരു സുരക്ഷിതവും idempotent-ഉം ആയ ഓപ്പറേഷനായി നിർവ്വചിക്കപ്പെട്ടിരിക്കുന്നു. ഒരേ QUERY request തുടർച്ചയായി പത്ത് തവണ അയച്ചാൽ സെർവറിൽ ഒരു പാർശ്വഫലവുമില്ലാതെ ഒരേ ഫലം ലഭിക്കും. ഡാറ്റ സൃഷ്ടിക്കപ്പെടുന്നില്ല, സ്റ്റേറ്റ് മാറുന്നില്ല, അബദ്ധത്തിൽ ഓഡിറ്റ് ട്രെയ്‌ലുകൾ ട്രിഗർ ചെയ്യപ്പെടുന്നില്ല.

ഇത് ഒരു request body-യെ പിന്തുണയ്ക്കുന്നു. POST പോലെ തന്നെ, നിങ്ങൾക്ക് സ്ട്രക്ചർഡ് ഡാറ്റ — JSON, XML, നിങ്ങളുടെ API ഉപയോഗിക്കുന്ന ഏതും — request body-യിൽ ഉൾപ്പെടുത്താം. നിങ്ങളുടെ സങ്കീർണ്ണമായ സെർച്ച് ഫിൽട്ടറുകൾ, നെസ്റ്റഡ് ഒബ്‌ജക്റ്റുകൾ, മൾട്ടി-കിലോബൈറ്റ് പേലോഡുകൾ എന്നിവ പൂർണ്ണമായും URL-ന് പുറത്ത് നിൽക്കുന്നു.

ഇത് വ്യക്തമായ ഉദ്ദേശ്യം സൂചിപ്പിക്കുന്നു. ഒരു സെർവറിന് ഒരു QUERY request ലഭിക്കുമ്പോൾ, ക്ലയന്റിന് എന്താണ് വേണ്ടതെന്നതിൽ ആശയക്കുഴപ്പമില്ല. ഇതിന് ഡാറ്റ വായിക്കണം. അത്രമാത്രം. ഈ POST ഒരു സെർച്ച് ആണോ അതോ ക്രിയേറ്റ് ഓപ്പറേഷൻ ആണോ എന്ന് സെർവർ ഊഹിക്കേണ്ടതില്ല.

ഇത് സ്വാഭാവികമായി കാഷെ ചെയ്യാൻ കഴിയും. POST താൽക്കാലിക പരിഹാരങ്ങളിൽ നിന്ന് വ്യത്യസ്തമായി, കൃത്യമായ കാഷിംഗ് സെമാന്റിക്സോടെ HTTP പ്രോട്ടോക്കോൾ ലെയറിലാണ് QUERY പ്രവർത്തിക്കുന്നത്. മെത്തേഡ് സെർവർ സ്റ്റേറ്റ് മാറ്റില്ല എന്ന് വ്യക്തമായി പ്രഖ്യാപിക്കുന്നതിനാൽ കാഷെകൾക്കും CDNs-നും QUERY റെസ്‌പോൺസുകൾ കാഷെ ചെയ്യാൻ കഴിയും — ഇത് POST-ന് ഒരിക്കലും ഉറപ്പുനൽകാൻ കഴിയാത്ത ഒന്നാണ്.

ഈ അവസാന പോയിന്റ് എടുത്ത് പറയേണ്ടതാണ്. GraphQL സങ്കീർണ്ണമായ ഫിൽട്ടറിംഗ് മനോഹരമായി കൈകാര്യം ചെയ്യുന്നു, എന്നാൽ ഇത് ആപ്ലിക്കേഷൻ ലെയറിലാണ് പ്രവർത്തിക്കുന്നത്. ഭൂരിഭാഗം GraphQL ക്വറികളും POST request ആയാണ് യാത്ര ചെയ്യുന്നത്, കൂടാതെ സെർവറുകൾ സാധാരണയായി POST റെസ്‌പോൺസുകൾ കാഷെ ചെയ്യാറില്ല. QUERY മെത്തേഡ് ട്രാൻസ്പോർട്ട് ലെയറിലാണ് പ്രവർത്തിക്കുന്നത്, അതായത് പ്രത്യേക ആപ്ലിക്കേഷൻ ലെയർ കോൺഫിഗറേഷൻ ഇല്ലാതെ തന്നെ HTTP ഇൻഫ്രാസ്ട്രക്ചറിന് — പ്രോക്സികൾ, CDNs, ലോഡ് ബാലൻസറുകൾ — കാഷിംഗിൽ പങ്കാളികളാകാം.

ഒരു QUERY Request എങ്ങനെയിരിക്കും

നിങ്ങൾ എപ്പോഴെങ്കിലും ഒരു HTTP request എഴുതിയിട്ടുണ്ടെങ്കിൽ, ഇത് പരിചിതമായി തോന്നും:

QUERY /api/analytics/events HTTP/1.1
Host: api.example.com
Content-Type: application/json
Accept: application/json

{
  "dateRange": {
    "start": "2026-01-01",
    "end": "2026-06-30"
  },
  "filters": {
    "regions": ["us-west-2", "eu-central-1"],
    "eventTypes": ["purchase", "refund"],
    "minAmount": 50.00
  },
  "groupBy": ["region", "month"],
  "limit": 100
}

അത്രതന്നെ. URL വൃത്തിയായിരിക്കുന്നു. body എല്ലാ സങ്കീർണ്ണതകളും വഹിക്കുന്നു. കൂടാതെ എല്ലാ HTTP ഇൻഫ്രാസ്ട്രക്ചറിനും ഈ request ഒരു റീഡ് ഓപ്പറേഷൻ ആണെന്ന് അറിയാം.

സുരക്ഷാ വശം: പുതിയ മെത്തേഡ്, പുതിയ അറ്റാക്ക് സർഫസ്

ഇവിടെയാണ് കാര്യങ്ങൾ രസകരവും — ഒപ്പം കുറച്ച് ഭയപ്പെടുത്തുന്നതുമാകുന്നത്.

സങ്കീർണ്ണമായ റീഡുകൾക്കായി GET, POST എന്നിവയുടെ ഘടനാപരമായ പ്രശ്നങ്ങൾ QUERY മെത്തേഡ് പരിഹരിക്കുന്നു. എന്നാൽ വെബിന്റെ ഇൻഫ്രാസ്ട്രക്ചറിലേക്ക് ഒരു പുതിയ HTTP മെത്തേഡ് അവതരിപ്പിക്കുന്നത് ആക്രമണകാരികൾക്കും സുരക്ഷാ ഗവേഷകർക്കും വലിയൊരു പുതിയ കളിക്കളം തുറന്നുനൽകുന്നു.

കാഷിംഗ് സങ്കീർണ്ണമാകുന്നു

QUERY കാഷെ ചെയ്യാവുന്നതാണ്, അതിന് ഒരു body-യുമുണ്ട്. ആ കോമ്പിനേഷൻ ഭൂരിഭാഗം HTTP ഇൻഫ്രാസ്ട്രക്ചറിനും പുതിയതാണ്.

പരമ്പരാഗത കാഷിംഗ് URL-ഉം ചില ഹെഡറുകളും കാഷെ കീ ആയി ഉപയോഗിക്കുന്നു. QUERY ഉപയോഗിക്കുമ്പോൾ, സെർവറുകളും പ്രോക്സികളും request body-യെക്കൂടി കാഷെ കീയിൽ ഉൾപ്പെടുത്തണം. ഒരു കാഷെ നടപ്പിലാക്കലിൽ ഇത് തെറ്റിയാൽ — ഉദാഹരണത്തിന് URL മാത്രം നോക്കി body അവഗണിച്ചാൽ — വ്യത്യസ്ത ഉപയോക്താക്കളുടെ തിരച്ചിൽ ഫലങ്ങൾ പരസ്പരം ചോർന്നേക്കാം.

കൂടുതൽ മോശമായി, request body-യിൽ നിന്നുള്ള സെൻസിറ്റീവ് ഡാറ്റ കാഷെ ലോഗുകളിലോ ഡീബഗ് ഔട്ട്പുട്ടുകളിലോ എത്തിയാൽ, നിങ്ങൾ ഒരു ലോഗിംഗ് പ്രശ്നത്തിന് (ആക്സസ് ലോഗുകളിലെ URL പാരാമീറ്ററുകൾ) പകരം മറ്റൊന്ന് (കാഷെ ഡീബഗ് ലോഗുകളിലെ request body-കൾ) വാങ്ങിവെക്കുകയാണ് ചെയ്യുന്നത്.

ക്ലാസിക് ദുർബലതകൾ, പുതിയ മാർഗ്ഗങ്ങൾ

ഓരോ പുതിയ HTTP മെത്തേഡും നിലവിലുള്ള ദുർബലതാ വിഭാഗങ്ങൾക്ക് പുതിയ അവസരങ്ങൾ നൽകുന്നു:

• ഇൻപുട്ട് വാലിഡേഷൻ പരാജയങ്ങൾ. നിങ്ങളുടെ WAF, POST body-കൾ വാലിഡേറ്റ് ചെയ്യുന്നത് പോലെ തന്നെ QUERY request body-കളും വാലിഡേറ്റ് ചെയ്യുന്നുണ്ടോ? ഇല്ലെങ്കിൽ, ഒരു ആക്രമണകാരിക്ക് നിങ്ങളുടെ പ്രതിരോധ സംവിധാനങ്ങളെ മറികടന്ന് ഹാനികരമായ പേലോഡുകൾ കടത്തിവിടാൻ കഴിഞ്ഞേക്കാം.
• റേറ്റ് ലിമിറ്റിംഗ് വിടവുകൾ. നിങ്ങളുടെ റേറ്റ് ലിമിറ്റർ GET, POST request-കൾ എണ്ണുകയും എന്നാൽ QUERY-യെ കുറിച്ച് അറിയിതിരിക്കുകയും ചെയ്താൽ, ആക്രമണകാരികൾക്ക് സൗജന്യ request-കൾ ലഭിക്കും.
• CSRF, CORS ആശയക്കുഴപ്പങ്ങൾ. ബ്രൗസറുകളും ഫ്രെയിംവർക്കുകളും QUERY-യുടെ ക്രോസ്-ഒറിജിൻ സെമാന്റിക്സ് ശരിയായി കൈകാര്യം ചെയ്യേണ്ടതുണ്ട്. ആദ്യഘട്ട സ്വീകാര്യതയിൽ, തെറ്റായ കോൺഫിഗറേഷനുകൾ ഉണ്ടാകാൻ വലിയ സാധ്യതയുണ്ട്.
• HTTP request സ്മഗ്ലിംഗ്. QUERY മനസ്സിലാകാത്ത ലോഡ് ബാലൻസറുകളും റിവേഴ്സ് പ്രോക്സികളും request-കൾ തെറ്റായി വിശകലനം ചെയ്തേക്കാം, ഇത് ഒരു request എവിടെ അവസാനിക്കുന്നുവെന്നും അടുത്തത് എവിടെ തുടങ്ങുന്നുവെന്നും ഫ്രണ്ട്-എൻഡും ബാക്ക്-എൻഡും തമ്മിൽ അഭിപ്രായവ്യത്യാസമുണ്ടാകുന്ന സ്മഗ്ലിംഗ് അവസരങ്ങൾ സൃഷ്ടിക്കുന്നു.
• മെത്തേഡ് ആശയക്കുഴപ്പം. ഒരു WAF അല്ലെങ്കിൽ മിഡിൽവെയർ ഒരു അജ്ഞാത മെത്തേഡ് കാണുകയും ഡിഫോൾട്ട് ഹാൻഡ്‌ലറിലേക്ക് പോവുകയും ചെയ്താൽ, അത് തെറ്റായ സുരക്ഷാ പോളിസി ബാധകമാക്കിയേക്കാം.

ഇവ കേവലം കാൽപ്പികമായ അപകടസാധ്യതകളല്ല. HTTP/2 അവതരിപ്പിച്ചപ്പോഴും, WebSockets വന്നപ്പോഴും, പ്രൊഡക്ഷൻ ഇൻഫ്രാസ്ട്രക്ചറിൽ മറ്റ് പ്രധാന പ്രോട്ടോക്കോൾ മാറ്റങ്ങൾ വന്നപ്പോഴും കാണപ്പെട്ട അതേ തരം ബഗ്ഗുകളാണിവ. ഈ രീതി വ്യക്തമാണ്: ടൂളുകൾ മെച്ചപ്പെടുന്നതുവരെ പുതിയ പ്രോട്ടോക്കോൾ സവിശേഷതകൾ താൽക്കാലിക സുരക്ഷാ വിടവുകൾ സൃഷ്ടിക്കുന്നു.

സ്വീകാര്യത ഇപ്പോൾ എവിടെ നിൽക്കുന്നു

2026 മധ്യത്തോടെ, സ്വീകാര്യത അതിന്റെ ആദ്യഘട്ടങ്ങളിലാണ്:

• ബ്രൗസറുകൾ പിന്തുണ നൽകാൻ തുടങ്ങിയിട്ടുണ്ട്, എന്നാൽ ഇത് ഇതുവരെ സാർവത്രികമായിട്ടില്ല.
• വെബ് ആപ്ലിക്കേഷൻ ഫയർവാളുകൾ QUERY request-കൾ തിരിച്ചറിയാനും ശരിയായി ഫിൽട്ടർ ചെയ്യാനും അവരുടെ റൂൾ സെറ്റുകൾ അപ്‌ഡേറ്റ് ചെയ്യുന്നു.
• CDNs QUERY-ക്കായി body-aware കാഷിംഗ് പിന്തുണ നൽകുന്നുണ്ട്, എന്നാൽ കോൺഫിഗറേഷനുകൾ വ്യത്യസ്തമാണ്.
• API ഫ്രെയിംവർക്കുകൾ — Express, FastAPI, Spring, ASP.NET — അവരുടെ ഏറ്റവും പുതിയ പതിപ്പുകളിൽ QUERY ഹാൻഡ്‌ലറുകൾ ചേർക്കുന്നു.
• HTTP ക്ലയന്റ് ലൈബ്രറികൾ QUERY request-കൾ അയക്കുന്നതിനെ പിന്തുണയ്ക്കുന്നതിനായി അപ്‌ഡേറ്റ് ചെയ്യപ്പെടുന്നു.

പൂർണ്ണവും വ്യാപകവുമായ സ്വീകാര്യതയ്ക്ക് സമയമെടുക്കും. ഇതൊരു പ്രോട്ടോക്കോൾ തലത്തിലുള്ള മാറ്റമാണ്, അതായത് സിസ്റ്റത്തിന്റെ ഓരോ ലെയറും — ബ്രൗസർ മുതൽ CDN, റിവേഴ്സ് പ്രോക്സി, ആപ്ലിക്കേഷൻ ഫ്രെയിംവർക്ക്, WAF വരെ — പുതിയ മെത്തേഡ് മനസ്സിലാക്കേണ്ടതുണ്ട്.

നിങ്ങൾ ഇപ്പോൾ എന്താണ് ചെയ്യേണ്ടത്

നിങ്ങൾ ഒരു ബാക്കെൻഡ് ഡെവലപ്പറോ API ഡിസൈനറോ ആണെങ്കിൽ:

1. RFC വായിക്കുക. RFC 9148 ആണ് പ്രധാന സ്പെസിഫിക്കേഷൻ. നടപ്പിലാക്കുന്നതിന് മുമ്പ് ഇതിന്റെ സെമാന്റിക്സ് മനസ്സിലാക്കുക.
2. നിങ്ങളുടെ ഇൻഫ്രാസ്ട്രക്ചർ പരിശോധിക്കുക (Audit ചെയ്യുക). നിങ്ങളുടെ റിവേഴ്സ് പ്രോക്സി, ലോഡ് ബാലൻസർ, WAF എന്നിവ QUERY request-കളെ ശരിയായി കടത്തിവിടുമോ എന്ന് പരിശോധിക്കുക. പഴയ പല കോൺഫിഗറേഷനുകളും അജ്ഞാതമായ HTTP മെത്തേഡുകളെ ഡിഫോൾട്ടായി ബ്ലോക്ക് ചെയ്യുന്നു.
3. പ്രൊഡക്ഷനിലേക്ക് തിരക്കിട്ട് പോകരുത്. ആന്തരിക API-കൾ അല്ലെങ്കിൽ ഡെവലപ്‌മെന്റ് എൻവയോൺമെന്റുകൾ ഉപയോഗിച്ച് ആരംഭിക്കുക. പൊതു ഇന്റർനെറ്റിലേക്ക് QUERY എൻഡ്പോയിന്റുകൾ തുറന്നുകൊടുക്കുന്നതിന് മുമ്പ് നിങ്ങളുടെ ടൂളുകൾ മെച്ചപ്പെടാൻ അനുവദിക്കുക.
4. നിങ്ങളുടെ കാഷിംഗ് തന്ത്രം അപ്‌ഡേറ്റ് ചെയ്യുക. QUERY റെസ്‌പോൺസുകൾ കാഷെ ചെയ്യാൻ നിങ്ങൾ ആഗ്രഹിക്കുന്നുവെങ്കിൽ, നിങ്ങളുടെ കാഷെ കീകളിൽ URL മാത്രമല്ല request body ഹാഷും ഉൾപ്പെടുന്നുവെന്ന് ഉറപ്പാക്കുക.
5. നിങ്ങളുടെ സുരക്ഷാ നിയന്ത്രണങ്ങൾ പരിശോധിക്കുക. റേറ്റ് ലിമിറ്റിംഗ്, ഇൻപുട്ട് വാലിഡേഷൻ, CORS, ഓതന്റിക്കേഷൻ എന്നിവയെല്ലാം QUERY-യിൽ ശരിയായി പ്രവർത്തിക്കുന്നുവെന്ന് സ്ഥിരീകരിക്കുക — പ്രവർത്തിക്കുമെന്ന് കരുതരുത്.

നിങ്ങൾ ഒരു സെക്യൂരിറ്റി ഗവേഷകനാണെങ്കിൽ, ഇതൊരു വലിയ അവസരമാണ്. പ്രൊഡക്ഷൻ ഇൻഫ്രാസ്ട്രക്ചറിലേക്ക് എത്തുന്ന ഒരു പുതിയ HTTP മെത്തേഡ് എന്നാൽ എല്ലായിടത്തും പുതിയ അറ്റാക്ക് സർഫസ് എന്നാണ് അർത്ഥമാക്കുന്നത്. QUERY-യെ കുറിച്ച് ഇപ്പോൾ പഠിക്കാൻ തുടങ്ങുക, കാരണം ആദ്യഘട്ട സ്വീകാര്യതയിൽ കാണപ്പെടുന്ന ബഗ്ഗുകളാണ് പലപ്പോഴും ഏറ്റവും വലിയ പ്രത്യാഘാതങ്ങൾ ഉണ്ടാക്കുന്നത്.

വലിയ ചിത്രം

QUERY മെത്തേഡ് ഒരു വിപ്ലവമല്ല. അതൊരു തിരുത്തലാണ്. 26 വർഷമായി, രണ്ട് മെത്തേഡുകളും ചെയ്യാൻ രൂപകൽപ്പന ചെയ്തിട്ടില്ലാത്ത ഒരു കാര്യത്തിനായി ഡെവലപ്പർമാർ GET, POST എന്നിവ ഉപയോഗിക്കുന്നു — കൂടാതെ സെക്യൂരിറ്റി ബഗ്ഗുകൾ, കാഷിംഗ് പരാജയങ്ങൾ, ആർക്കിടെക്ചറൽ ബുദ്ധിമുട്ടുകൾ എന്നിവയുടെ രൂപത്തിൽ അതിന് വലിയ വില നൽകുകയും ചെയ്യുന്നു.

QUERY, GET-ന് പകരമാകുന്നില്ല. ഇത് POST-നും പകരമാകുന്നില്ല. വർഷങ്ങൾക്ക് മുമ്പ് നികത്തേണ്ടിയിരുന്ന ഒരു വിടവാണ് ഇത് നികത്തുന്നത്: ഒരു request body-യെ പിന്തുണയ്ക്കുന്ന സുരക്ഷിതവും റീഡ്-ഓൺലിയുമായ HTTP മെത്തേഡ്.

പ്രോട്ടോക്കോൾ ഔദ്യോഗികമാണ്. RFC പ്രസിദ്ധീകരിച്ചു. ഇക്കോസിസ്റ്റം അതിനനുസരിച്ച് മാറിക്കൊണ്ടിരിക്കുന്നു. നിങ്ങൾ API-കൾ നിർമ്മിക്കുകയാണെങ്കിലും, ഇൻഫ്രാസ്ട്രക്ചർ സുരക്ഷിതമാക്കുകയാണെങ്കിലും, അല്ലെങ്കിൽ ദുർബലതകൾ കണ്ടെത്തുകയാണെങ്കിലും — QUERY മെത്തേഡ് നിങ്ങൾ മനസ്സിലാക്കേണ്ട ഒന്നാണ്.

വെബിന് ഒരു പുതിയ ക്രിയ (verb) ലഭിച്ചിരിക്കുന്നു. അത് ബുദ്ധിപൂർവ്വം ഉപയോഗിക്കുക.

ഗുണങ്ങൾ (Merits)

• URL നീള പരിധികൾ പരിഹരിക്കുന്നു: സങ്കീർണ്ണമായ സെർച്ച് പേലോഡുകൾ URL-ൽ നിന്ന് request body-യിലേക്ക് മാറുന്നു — ഇനി വെട്ടിച്ചുരുക്കലുകളില്ല
• സുരക്ഷാ മെച്ചപ്പെടുത്തൽ: സെൻസിറ്റീവായ സെർച്ച് പാരാമീറ്ററുകൾ ബ്രൗസർ ഹിസ്റ്ററിയിലും, ആക്സസ് ലോഗുകളിലും, പ്രോക്സി കാഷെകളിലും ചോരുന്നില്ല
• ശരിയായ സെമാന്റിക്സ് (Correct semantics): സെർവറുകൾക്കും മിഡിൽവെയറുകൾക്കും WAFs-നും ഊഹിക്കാതെ തന്നെ റീഡുകളും റൈറ്റുകളും വേർതിരിച്ചറിയാൻ കഴിയും
• സ്വാഭാവിക കാഷെ ചെയ്യാനുള്ള കഴിവ് (Native cacheability): POST താൽക്കാലിക പരിഹാരങ്ങളിൽ നിന്ന് വ്യത്യസ്തമായി, HTTP ഇൻഫ്രാസ്ട്രക്ചറിന് QUERY റെസ്‌പോൺസുകൾ കാഷെ ചെയ്യാൻ കഴിയും
• Idempotent-ഉം സുരക്ഷിതവും: റീട്രൈകൾ ദോഷകരമല്ല, ഇത് വിതരണം ചെയ്ത സിസ്റ്റങ്ങളിലെ (distributed systems) എറർ ഹാൻഡ്‌ലിംഗ് ലളിതമാക്കുന്നു
• പ്രോട്ടോക്കോൾ തലത്തിലുള്ള പരിഹാരം: GraphQL പോലുള്ള ആപ്ലിക്കേഷൻ തലത്തിലുള്ള താൽക്കാലിക പരിഹാരങ്ങൾ ആവശ്യമില്ലാതെ എല്ലാ REST APIs-ലും പ്രവർത്തിക്കുന്നു

ദോഷങ്ങൾ (Demerits)

• പുതിയ അറ്റാക്ക് സർഫസ്: സ്മഗ്ലിംഗ്, മെത്തേഡ് ആശയക്കുഴപ്പം, CSRF, CORS പ്രശ്നങ്ങൾ എന്നിവയ്ക്ക് പുതിയ വഴിതുറക്കുന്നു
• കാഷിംഗ് സങ്കീർണ്ണത: കാഷെ നടപ്പിലാക്കലുകൾ കീകളിൽ request body ഉൾപ്പെടുത്തണം — തെറ്റായ കോൺഫിഗറേഷൻ ഡാറ്റ ചോർത്തുന്നു
• മന്ദഗതിയിലുള്ള സ്വീകാര്യത: ഇത് തുടക്കം മുതൽ ഒടുക്കം വരെ വിശ്വസനീയമായി പ്രവർത്തിക്കുന്നതിന് ബ്രൗസറുകൾ, CDNs, WAFs, ഫ്രെയിംവർക്കുകൾ എന്നിവയ്ക്കെല്ലാം അപ്‌ഡേറ്റുകൾ ആവശ്യമാണ്
• ടൂളിംഗ് വിടവുകൾ: ഡീബഗ്ഗിംഗ് ടൂളുകൾ, മോണിറ്ററിംഗ് ഡാഷ്‌ബോർഡുകൾ, ലോഗ് പാഴ്‌സറുകൾ എന്നിവയ്ക്ക് QUERY ഇതുവരെ കൈകാര്യം ചെയ്യാൻ കഴിഞ്ഞേക്കില്ല
• ഇൻഫ്രാസ്ട്രക്ചർ തടസ്സങ്ങൾ: പഴയ റിവേഴ്സ് പ്രോക്സികളും ലോഡ് ബാലൻസറുകളും QUERY റിക്വസ്റ്റുകൾ നിശബ്ദമായി ഉപേക്ഷിക്കുകയോ നിരസിക്കുകയോ ചെയ്തേക്കാം
• തെറ്റായ സുരക്ഷാ ബോധം: URL-കളിൽ നിന്ന് പാരാമീറ്ററുകൾ മാറ്റുന്നത് ലോഗിംഗ് അപകടസാധ്യതകളെ ഇല്ലാതാക്കുന്നില്ല — ബോഡികൾ ഇപ്പോഴും ലോഗ് ചെയ്യപ്പെടാം

ജാഗ്രത

2026 ജൂണിൽ സ്റ്റാൻഡേർഡൈസ് ചെയ്ത RFC 9148-ൽ നിർവചിച്ചിരിക്കുന്ന QUERY HTTP മെത്തേഡിനെക്കുറിച്ചാണ് ഈ ലേഖനം ചർച്ച ചെയ്യുന്നത്. ബ്രൗസർ പിന്തുണ, ഫ്രെയിംവർക്ക് പിന്തുണ, ഇൻഫ്രാസ്ട്രക്ചർ കോംപാറ്റിബിലിറ്റി എന്നിവ വേഗത്തിൽ വികസിച്ചുകൊണ്ടിരിക്കുകയാണ്. CDN മുതൽ WAF വരെയുള്ളതും ആപ്ലിക്കേഷൻ ഫ്രെയിംവർക്ക് വരെയുമുള്ള നിങ്ങളുടെ സ്റ്റാക്കിന്റെ ഓരോ ലെയറും പുതിയ മെത്തേഡ് ശരിയായി കൈകാര്യം ചെയ്യുന്നുണ്ടെന്ന് ഉറപ്പുവരുത്താതെ പ്രൊഡക്ഷനിൽ QUERY എൻഡ്‌പോയിന്റുകൾ ഡിപ്ലോയ് ചെയ്യരുത്. ഇവിടെ വിവരിച്ചിരിക്കുന്ന സുരക്ഷാ സവിശേഷതകൾ ശരിയായ ഇംപ്ലിമെന്റേഷനെ അടിസ്ഥാനമാക്കിയുള്ളതാണ്; തെറ്റായി കോൺഫിഗർ ചെയ്ത ഇൻഫ്രാസ്ട്രക്ചർ QUERY തടയാൻ രൂപകൽപ്പന ചെയ്തിട്ടുള്ള സുരക്ഷാ ഭീഷണികൾ തന്നെ സൃഷ്ടിച്ചേക്കാം. എപ്പോഴും ആദ്യം ഒരു കൺട്രോൾഡ് എൻവയോൺമെന്റിൽ ടെസ്റ്റ് ചെയ്യുക.

പതിവായി ചോദിക്കുന്ന ചോദ്യങ്ങൾ

• എന്താണ് HTTP QUERY മെത്തേഡ്, അത് GET-ൽ നിന്ന് എങ്ങനെ വ്യത്യസ്തമാണ്?
• എനിക്ക് ഇപ്പോൾ പ്രൊഡക്ഷൻ API-കളിൽ QUERY ഉപയോഗിക്കാമോ?
• POST വഴി സെർച്ച് പേലോഡുകൾ അയക്കുന്നതുമായി താരതമ്യം ചെയ്യുമ്പോൾ QUERY എങ്ങനെയാണ്?
• CDN-കളും പ്രോക്സികളും QUERY റെസ്‌പോൺസുകൾ ശരിയായി കാഷെ ചെയ്യുമോ?
• QUERY മെത്തേഡ് എന്തെല്ലാം സുരക്ഷാ അപകടസാധ്യതകൾ കൊണ്ടുവരുന്നു?
• സങ്കീർണ്ണമായ ഡാറ്റാ ഫെച്ചിംഗിനായി QUERY, GraphQL-ന് പകരമാകുമോ?
• എന്റെ Express അല്ലെങ്കിൽ FastAPI ആപ്ലിക്കേഷനിലേക്ക് QUERY സപ്പോർട്ട് എങ്ങനെ ചേർക്കാം?
• എന്റെ WAF, QUERY മെത്തേഡിനെ തിരിച്ചറിഞ്ഞില്ലെങ്കിൽ എന്ത് സംഭവിക്കും?

ടാഗുകൾ

#http #query-method #rfc-9148 #api-design #web-security #rest-api #caching #http-methods