Saya Melarang Query String

 (chrismorgan.info)
1 poin oleh GN⁺ 5 jam lalu | 1 komentar | Bagikan ke WhatsApp
  • Chris Morgan memutuskan untuk memblokir sepenuhnya query string yang tidak sah di situsnya, dan implementasinya saat ini ada di Caddyfile
  • Ia tidak ingin parameter pelacakan seperti ?ref=example.com ditambahkan ke URL miliknya, dan menurutnya jika perlu cukup melihat header Referer
  • Ia berpendapat bahwa UTM parameters seperti ?utm_source=example&utm_*&c.* adalah untuk digunakan oleh pemilik situs, bukan untuk ditempelkan dari luar
  • Saat ini situs tersebut sama sekali tidak menggunakan query string, dan jika nanti digunakan, ia berencana hanya mengizinkan parameter yang dikenal
  • URL akhirnya diputuskan sebagai /no-query-strings, dan /%3F tidak dipilih karena ada masalah pada penulisan ulang try_files di Caddy

Memblokir Query String yang Tidak Sah

  • Chris Morgan memutuskan untuk memblokir sepenuhnya query string yang tidak sah di situsnya
  • Ia tidak ingin parameter pelacakan seperti ?ref=example.com ditambahkan ke URL miliknya, dan menurutnya jika perlu cukup melihat header Referer
  • Ia berpendapat bahwa UTM parameters seperti ?utm_source=example&utm_*&c.* adalah untuk digunakan oleh pemilik situs, bukan untuk ditempelkan dari luar
  • Saat ini situs ini sama sekali tidak menggunakan query string, dan jika nanti digunakan, ia berencana hanya mengizinkan parameter yang dikenal
  • Di masa lalu ia menggunakan URL pembatalan cache seperti ?t=…, ?h=… pada URL stylesheet, tetapi ia menilai tidak masalah jika permintaan seperti itu rusak
  • Pemblokiran ini saat ini diimplementasikan di Caddyfile

Proses Memilih URL

  • Rencana untuk menggunakan /?

    • Awalnya ia sangat tergoda untuk menerbitkan halaman ini di https://chrismorgan.info/?
    • Bentuknya berupa path kosong dan query kosong, sehingga bisa meruntuhkan banyak asumsi umum yang keliru dan berpotensi menyulitkan beberapa alat
    • curl tampaknya secara tidak semestinya menghapus tanda tanya di akhir pada baris perintah, dan penggunaan lewat library tidak diuji
    • Pada akhirnya ia memutuskan untuk menghormati konsep path dan bersikap lebih ramah kepada orang, terutama karena menurutnya Caddy sudah didorong ke arah yang cukup tidak nyaman

  • Rencana untuk menggunakan /%3F

  • Pilihan akhir

    • URL akhirnya diputuskan sebagai /no-query-strings
    • /? atau /%3F mungkin nanti digunakan untuk keperluan lain terkait query string

Bacaan terkait

1 komentar

 
GN⁺ 5 jam lalu
Opini Hacker News

  • Saya penasaran soal ini, jadi saya melihat lagi standar W3C untuk HTML dan URL, dan ternyata secara mengejutkan tidak ada definisi khusus untuk format query string selain percent-encoding
    Query string bisa saja tertukar dengan query string “form-urlencoded”[0], tetapi itu hanyalah salah satu format yang interoperabel. Secara umum, query string adalah sembarang string yang di-percent-encode setelah ? pada URL[1], dan merupakan properti lain dari objek URL HTML yang dapat dipakai untuk menghasilkan respons
    Objek URLSearchParams adalah hasil parsing query string dengan parser form-urlencoded, tetapi itu hanyalah lapisan interoperabilitas untuk JavaScript
    Jujur, sebelum melihat standarnya saya siap untuk tidak setuju, tetapi standarnya cukup jelas. Merespons dengan 404 untuk query string yang tidak diharapkan juga bisa dianggap tepat. Query string adalah bagian dari API URL sama seperti path, dan kebanyakan orang mungkin setuju bahwa menambahkan string sembarangan ke path bukanlah hal yang baik dan merupakan perilaku yang tidak terdefinisi
    [0]: https://url.spec.whatwg.org/#application/x-www-form-urlencod...
    [1]: https://url.spec.whatwg.org/#url-class

    • Dulu cukup umum CMS atau forum hanya punya satu index.php, lalu semua routing ditangani lewat query string
      Tentu saja formatnya form-urlencoded, orang-orang juga bukan barbar. Jadi muncul URL seperti index.php?p=home, index.php?p=shop, atau index.php?action=showthread&forum=42&thread=17976. Dalam struktur seperti ini, langsung terlihat bahwa 404 memang respons yang tepat untuk parameter query yang tidak dikenal
      Bahkan sekarang pun banyak situs masih bekerja seperti itu, hanya disembunyikan di balik beberapa aturan rewrite Apache/nginx demi SEO
    • Betul, URL sebenarnya tidak punya banyak semantik. Path tampak jelas dimaksudkan untuk data hierarkis, query untuk data non-hierarkis, ada kebiasaan yang kuat, dan sebagian bahkan didukung atau dipaksakan oleh library, tetapi aturan nyata tidak ada
      Pada akhirnya URL hanyalah string yang server putuskan bagaimana cara memprosesnya
      Hal yang benar-benar lucu dari diskusi ini adalah, sambil khawatir soal efek samping jika merespons 404, orang-orang benar-benar lupa betapa lamanya path tidak punya makna dalam sejarah web. Sekarang path menang. Hampir tidak ada lagi yang memulai baru dengan URL seperti /item?id=…. Bagus!
    • Saya rasa 400 yang umum mungkin lebih baik. Halamannya bukan tidak ditemukan, tetapi permintaannya tidak diizinkan
      Ini terbaca sebagai “perbaiki permintaan lalu coba lagi”, dan saya juga memakainya begitu di API yang saya sediakan. Saya lebih memilih ini daripada 406 karena masalahnya bukan sesuatu yang tidak bisa saya proses. Jika seseorang mencoba merusaknya dengan menambahkan sesuatu ke query string, atau membuat request yang tidak sesuai dokumentasi, itu tanggung jawab peminta
    • Proposal No-Vary-Search memungkinkan Anda menentukan bagian query mana yang relevan
      https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/...
      Misalnya dari sudut pandang caching, url?a=b&c=d bisa dianggap cocok dengan url?c=d&a=b
    • Standar hanyalah perilaku yang diterima luas, yang dituliskan seseorang di suatu tempat
      Ada banyak sekali kebiasaan yang belum pernah didokumentasikan sebagai standar resmi tetapi akan merusak banyak hal jika tidak diikuti, dan juga banyak “standar” yang membuat orang tampak bodoh jika diikuti secara harfiah
      Dalam kasus tulisan aslinya, yang rusak hanyalah orang yang ingin mengunjungi situs itu, dan kemungkinan mereka akan menekan tombol kembali di browser lalu lanjut dengan urusan mereka. Apakah kerugian sebesar itu bisa diterima atau tidak, silakan putuskan sendiri. Hanya saja, bukan berarti sesuatu boleh dilakukan secara definisi hanya karena tidak dilarang standar, dan sebaliknya, bukan berarti jadi tiba-tiba tidak boleh hanya karena dilarang standar

  • Dari yang saya pahami, penulis tampaknya kesal karena situs lain menambahkan query string seperti ?ref=origin.com pada tautan menuju situs penulis
    Saya tidak paham apa keuntungan untuk situs asal dan apa kerugian untuk situs penulis
    Perilaku kedua belah pihak sama-sama terasa sangat membingungkan
    Saya paham ketika menjalankan kampanye iklan, Google menambahkan query string UTM untuk melacak dari kampanye mana pengguna datang. Dalam hal itu, asal dan tujuan memang bekerja sama. Tetapi di sini, pihak asal menambahkan sesuatu tanpa alasan yang jelas. Kenapa?

    • Dari sudut pandang situs asal, itu marketing. Alurnya adalah penulis melihat dari query string ref bahwa banyak traffic datang dari xyz.com, lalu berpikir mungkin layak beriklan atau berafiliasi dengan situs itu
      Sejujurnya ini cukup berguna untuk situs niche/startup. Saya pernah mengalami kedua sisi percakapan yang dimulai dari melihat nilai seperti ini di web analytics: satu kali saya yang menghubungi setelah melihat traffic rujukan, dan di lain waktu situs yang saya tautkan yang menghubungi saya. Kedua-duanya berakhir sebagai kemitraan yang saling menguntungkan
      Saya juga agak memahami argumen privasinya, tetapi ini tidak memberi informasi lebih banyak daripada header Referer standar. Hanya saja, jika memakai alat analitik seperti Simple Analytics/Plausible, hal itu jadi jauh lebih terlihat jelas
    • Secara umum saya menentang pelacakan. Pelacakan biasanya bertentangan dengan kepentingan individu
      Menambahkan query string sering dipakai untuk pelacakan. Hanya dari fakta bahwa ada fitur seperti “copy clean link” di Firefox atau Enhanced Tracking Protection yang secara proaktif menghapus sebagian parameter UTM, kita bisa melihat banyak orang tidak menginginkan ini
      Beberapa situs dengan sukarela ikut dalam sistem yang secara santai saya sebut “ekonomi pelacakan”. Penerima dapat melihat di log bahwa banyak orang datang dari situs mereka, lalu melakukan tindakan yang menguntungkan situs tersebut
      Menolak query string adalah bentuk protes sederhana terhadap sistem itu
    • Jika situs web populer menambahkan parameter itu, situs tujuan bisa dengan mudah tahu siapa yang mengirim traffic, dan itu bisa menjadi dasar sponsorship atau perjanjian afiliasi

  • Melihat deskripsi “konsol web kecil, terdesentralisasi, self-hosted, yang memungkinkan pengunjung situs web menjelajahi situs dan halaman menarik yang direkomendasikan komunitas operator situs web pribadi independen”, dulu hal seperti ini disebut Webring. Hanya saja tidak se-wah itu
    Salah satu masalah yang saya alami saat mengembangkan framework aplikasi open source adalah hosting yang memakai FastCGI tidak menghormati header Auth, sehingga token terpaksa dikirim lewat query. Saat orang copy-paste alamat web, token itu sering ikut terbawa, dan itu benar-benar buruk. Mungkin sekarang sudah diperbaiki
    Untuk backend yang saya kendalikan dan tidak perlu dibuka ke semua orang, saya memakai header

    • Saya menulis framework aplikasi open source dengan fcgi-app, jadi maksudnya misalnya Apache merusak header Auth?
      Saya penasaran apakah Anda bisa menjelaskan bagian ini lebih rinci. Secara teknis, kedengarannya seperti record PARAM tidak benar-benar memberikan nilai yang diharapkan

  • Ia mengatakan, “Jadi saya memutuskan untuk mencoba larangan menyeluruh di situs ini: tidak ada query string yang tidak disetujui”, tetapi situsnya tampaknya mengembalikan 414 jika request mengandung query string, dan menurut saya itu pilihan yang salah
    Jika protes ini dimaksudkan untuk membela pengguna, kenapa justru menghukum pengguna yang sejak awal mungkin tidak bisa mengendalikan string itu?
    Bukankah lebih baik dipakai sebagai sinyal untuk memberi tahu pengguna cara agar mereka bisa membuat keputusan ini sendiri, misalnya lewat alat browser?

    • “Anda bisa bilang saya menyalahgunakan 414 URI Too Long. Jawaban saya: cara ini lebih lucu. Pilihan lain yang saya pertimbangkan adalah:
      400 Bad Request, benar sebagai kode kesalahan klien umum, tetapi tidak lucu
      402 Payment Required, sejujurnya saya terbuka jika seseorang mau membayar agar URL tertentu dengan query string berfungsi
      404 Not Found, tetapi terlalu mudah menimbulkan efek samping dan tidak menyampaikan nuansa ‘format request Anda salah’ yang saya inginkan
      303 See Other tanpa header Location. Ini sangat jarang sekarang, tetapi sah. Setidaknya begitu menurut RFC 2616 (“The different URI SHOULD be given by the Location field in the response”). Tetapi di 7231 dan 9110 berubah menjadi seolah mengandaikan keberadaan header Location (“… as indicated by a URI in the Location header field”). Sementara itu, 301, 302, 307, 308 mengatakan “the server SHOULD generate a Location header field”. Bagaimanapun, menurut saya See Other tanpa header Location tetap cukup oke. Tapi URI Too Long lebih lucu”
      https://chrismorgan.info/no-query-strings?foo
    • Sudah lama sekali jadi saya agak samar, tetapi saya rasa pernah ada versi halaman server PLSQL yang akan mengembalikan 500 jika diberi query string yang tidak dikenal

  • Pada bagian “Anda bisa bilang saya menyalahgunakan 414 URI Too Long. Jawaban saya: cara ini lebih lucu. Pilihan lain yang saya pertimbangkan adalah…”, pilihan lain yang juga bisa dipikirkan adalah 418 I'm a teapot. Toh teko biasanya juga tidak mendukung query string

    • 400 “Bad Request” atau 403 “Forbidden” tampaknya juga bisa dipertahankan sebagai pilihan. Agak aneh tidak ada kode respons kesalahan khusus untuk parameter URI
      Ada beberapa pilihan yang kelihatannya cocok tetapi ternyata tidak jika dilihat lebih dekat: 406 “Not Acceptable” berbasis header negosiasi konten, 409 “Conflict” terutama untuk request WebDAV, dan 411, 422, 431 juga untuk kondisi spesifik yang tidak relevan di sini
      Error seri 300 maupun 500 juga tidak tepat. Ini bukan relokasi ataupun kegagalan sisi server, melainkan masalah pada request sisi klien
      Teko atau terlalu panjang tampaknya kandidat terbaik
    • Tentu mendukung. Misalnya, dengan menjatuhkan tali dari atas Anda bisa menanyakan level air teko, atau dengan melilitkan tali di sekeliling teko Anda bisa menanyakan kelilingnya
    • Tapi saya bukan teko. Saya tidak suka teh

  • Dari nada tulisan ini dan tulisan Chris, rasanya memasukkan parameter query seperti ini seolah berbahaya, tetapi saya tidak paham bahayanya di mana
    Saya paham ini bisa merusak beberapa URL, dan itu saja sudah cukup jadi alasan untuk tidak melakukannya. Namun selain itu, ini tampak seperti ketidaknyamanan kecil. Bisa ada yang menjelaskan?

    • Ada tiga sudut pandang
      Dari sudut pandang purisme teknis, memodifikasi URL tetap tidak tepat secara teknis meskipun diterima sebagai kebiasaan. URL pada dasarnya harus diperlakukan sebagai nilai opak
      Dari sudut pandang sosial, ini adalah pelacakan, dan thread komentar saudara sudah menjelaskannya dengan baik jadi saya tidak akan mengulanginya
      Dari sudut pandang kebisingan, ini menutupi bagian yang perlu diperhatikan pengguna dan membuat URL jadi terlalu sulit serta rumit, sehingga ikut membuat orang awam tidak lagi peduli pada URL
    • Jika membaca masalah terkait header HTTP Referer, Anda bisa memahami kenapa orang tidak menyukainya: https://en.wikipedia.org/wiki/HTTP_referer
      Ada banyak alasan mengapa seseorang tidak ingin situs yang dituju mengetahui di mana ia berada sebelum sampai ke situs tersebut. Pada dasarnya ini seperti membagikan riwayat penelusuran Anda kepada situs yang sedang dikunjungi
      Itulah sebabnya header HTTP Referer telah mendapat banyak pembaruan, termasuk pembatasan kondisi pengiriman dan fitur untuk mematikannya sepenuhnya
      Menambahkan informasi yang sama sebagai parameter URL akan melewati aturan dan opsi penolakan yang sudah ada ini. Gunakan saja standar yang ada
    • Tidak ada alasan sama sekali. Informasi itu tinggal dibuang saja
      Ini sikap yang kelewat ekstrem, dan tidak benar-benar menjelaskan bagaimana ini akan menghasilkan web yang lebih baik
    • Menariknya, tidak satu pun dari situs-situs seperti ini punya fitur pencarian. Pencarian adalah fitur aksesibilitas yang penting dan merupakan kasus penggunaan query string yang jelas dan sah
    • Ada beberapa alasan. Pengguna tidak menyetujui pelacakan, dan parameter query seperti ini adalah informasi pelacakan. Selain itu, pengelola situs mungkin juga tidak ingin traffic masuk mereka dilacak
      Yang terakhir mungkin sulit dipahami, tetapi dalam kasus saya, saya sama sekali tidak ingin ada informasi di log yang bisa merugikan pengguna
      Secara pribadi saya juga sangat tidak suka ketika ingin menyalin tautan untuk dikirim lewat pesan, tetapi ada kode pelacakan yang dua kali lebih panjang daripada URL aslinya. Saya jadi harus menghapusnya satu per satu, atau membiarkan penerima bertanya-tanya apa sebenarnya deretan karakter acak sepanjang layar itu
      Ini melanggar privasi pengguna, pengalaman pengguna juga buruk, dan yang terpenting, tidak ada yang memintanya

  • Karena sumber asli belum pernah dibahas di HN, saya menaruh tautan itu (https://chrismorgan.info/no-query-strings) di bagian paling atas dan memindahkan tautan ke tulisan tanggapan (https://susam.net/no-query-strings.html) ke penjelasan atas
    Keduanya bagus, tetapi terasa lebih adil memberi prioritas pada tulisan asli

  • Di sekitar saya, sebagian besar situs yang masih memakai GET query sekarang adalah situs penagihan pajak milik pemerintah daerah, yang mengoper variabel ke sana kemari setelah login
    Sejujurnya parser routing yang pura-pura jadi URL sungguhan padahal melakukan hal yang sama dengan request GET justru jauh lebih menjengkelkan

  • Query string itu berguna. Misalnya untuk pencarian file atau jenis file dinamis lain, tetapi tidak seharusnya ditambahkan ke URL yang tidak mengharapkannya
    Jadi saya rasa menolak request yang ditambahi hal seperti UTM itu memang benar
    Jika query string tidak diharapkan tetapi tetap ada, sebagai respons 404 tampaknya paling masuk akal, dan 400 juga bisa dianggap tepat