Cara Menangani Permintaan

ID region

REGION_ID adalah kode singkat yang ditetapkan Google berdasarkan region yang Anda pilih saat membuat aplikasi. Kode ini tidak sesuai dengan negara atau provinsi, meskipun beberapa ID region mungkin tampak mirip dengan kode negara dan provinsi yang umum digunakan. Untuk aplikasi yang dibuat setelah Februari 2020, REGION_ID.r disertakan dalam URL App Engine. Untuk aplikasi lama yang dibuat sebelum tanggal tersebut, ID region bersifat opsional dalam URL.

Pelajari ID region lebih lanjut.

Oke

Dokumen ini menjelaskan cara aplikasi App Engine Anda menerima permintaan dan mengirim respons.

Untuk mengetahui detail selengkapnya, lihat Referensi Header dan Respons Permintaan.

Jika aplikasi Anda menggunakan layanan, Anda dapat mengajukan permintaan ke layanan tertentu atau versi tertentu dari layanan tersebut. Untuk mengetahui informasi selengkapnya tentang cara respons layanan, lihat Cara Permintaan Dirutekan.

Menangani permintaan

Aplikasi Anda bertanggung jawab memulai server web dan menangani permintaan. Anda dapat menggunakan framework web apa pun yang tersedia untuk bahasa pengembangan Anda.

App Engine menjalankan beberapa instance aplikasi Anda, dan setiap instance memiliki server web sendiri untuk menangani permintaan. Setiap permintaan dapat dirutekan ke instance mana saja, sehingga permintaan berturut-turut dari pengguna yang sama belum tentu dikirim ke instance yang sama. Satu instance dapat menangani beberapa permintaan secara serentak. Jumlah instance dapat disesuaikan secara otomatis saat traffic berubah. Anda juga dapat mengubah jumlah permintaan serentak yang dapat ditangani instance dengan menyetel elemen max_concurrent_requests di file app.yaml Anda.

Saat menerima permintaan web untuk aplikasi Anda, App Engine akan memanggil skrip pengendali yang sesuai dengan URL, seperti yang dijelaskan dalam file konfigurasi app.yaml aplikasi. Runtime Python 2.7 mendukung standar WSGI dan standar CGI untuk kompatibilitas mundur. WSGI lebih disarankan, dan beberapa fitur Python 2.7 tidak akan berfungsi tanpanya. Konfigurasi pengendali skrip aplikasi Anda akan menentukan apakah permintaan ditangani menggunakan WSGI atau CGI.

Skrip Python berikut merespons permintaan dengan header HTTP dan pesan Hello, World!.

import webapp2


class MainPage(webapp2.RequestHandler):
    def get(self):
        self.response.headers["Content-Type"] = "text/plain"
        self.response.write("Hello, World!")


app = webapp2.WSGIApplication(
    [
        ("/", MainPage),
    ],
    debug=True,
)

Untuk mengirim beberapa permintaan ke setiap server web secara paralel, tandai aplikasi Anda sebagai threadsafe dengan menambahkan threadsafe: true ke file app.yaml Anda. Permintaan serentak tidak tersedia jika pengendali skrip menggunakan CGI.

Kuota dan batas

App Engine otomatis mengalokasikan resource ke aplikasi Anda saat traffic meningkat. Namun, ini terikat oleh pembatasan berikut:

• App Engine mencadangkan kapasitas penskalaan otomatis untuk aplikasi dengan latensi rendah, saat aplikasi merespons permintaan dalam waktu kurang dari satu detik.

• Aplikasi yang sangat terikat dengan CPU juga dapat menimbulkan beberapa latensi tambahan untuk berbagi resource secara efisien dengan aplikasi lain di server yang sama. Permintaan untuk file statis dikecualikan dari batas latensi ini.

Setiap permintaan yang masuk ke aplikasi akan dihitung dalam batas Permintaan. Data yang dikirim sebagai respons terhadap permintaan akan dihitung dalam batas Bandwidth Keluar (dapat ditagih).

Permintaan HTTP dan HTTPS (aman) diperhitungkan dalam batas Permintaan, Bandwidth Masuk (dapat ditagih), dan Bandwidth Keluar (dapat ditagih). Halaman Detail Kuota konsol Google Cloud juga melaporkan Permintaan Aman, Bandwidth Masuk Aman, dan Bandwidth Keluar Aman sebagai nilai terpisah untuk tujuan informasi. Hanya permintaan HTTPS yang diperhitungkan dalam nilai ini. Untuk mengetahui informasi selengkapnya, lihat halaman Kuota.

Batas berikut berlaku khusus untuk penggunaan pengendali permintaan:

Batas	Jumlah
Ukuran permintaan	32 megabyte
Ukuran respons	32 megabyte
Waktu tunggu permintaan	Tergantung jenis penskalaan yang digunakan aplikasi Anda
Jumlah total maksimum file (file aplikasi dan file statis)	Total 10.000 1.000 per direktori
Ukuran maksimum file aplikasi	32 megabyte
Ukuran maksimum file statis	32 megabyte
Ukuran total maksimum untuk semua file aplikasi dan file statis	Gratis 1 gigabyte pertama $ 0,026 per gigabyte per bulan setelah 1 gigabyte pertama
Waktu tunggu permintaan tertunda	10 detik
Ukuran maksimum satu kolom header permintaan	8 kilobyte untuk runtime generasi kedua di lingkungan standar. Permintaan ke runtime ini dengan kolom header yang melebihi 8 kilobyte akan menampilkan error HTTP 400.

Batas permintaan

Semua permintaan HTTP/2 akan diterjemahkan menjadi permintaan HTTP/1.1 saat diteruskan ke server aplikasi.

Batas respons

• Respons dinamis dibatasi hingga 32 MB. Jika pengendali skrip menghasilkan respons yang lebih besar dari batas ini, server akan mengirim kembali respons kosong dengan kode status Error Server Internal 500. Batasan ini tidak berlaku untuk respons yang menyalurkan data dari Blobstore lama atau Cloud Storage.

• Batas header respons adalah 8 KB untuk runtime generasi kedua. Header respons yang melebihi batas ini akan menampilkan error HTTP 502, dengan log yang menampilkan upstream sent too big header while reading response header from upstream.

Header permintaan

Permintaan HTTP masuk menyertakan header HTTP yang dikirim oleh klien. Untuk tujuan keamanan, beberapa header dibersihkan atau diubah oleh proxy perantara sebelum mencapai aplikasi.

Untuk mengetahui informasi selengkapnya, lihat Referensi header permintaan.

Menangani waktu tunggu permintaan

App Engine dioptimalkan untuk aplikasi dengan permintaan berumur pendek, biasanya yang memerlukan waktu beberapa ratus milidetik. Aplikasi yang efisien akan merespons sebagian besar permintaan dengan cepat. Aplikasi yang tidak diskalakan dengan baik dengan infrastruktur App Engine. Untuk memastikan tingkat performa ini, ada waktu tunggu permintaan maksimum yang diberlakukan oleh sistem yang harus direspons oleh setiap aplikasi.

Jika aplikasi Anda melebihi batas waktu ini, App Engine akan menginterupsi pengendali permintaan. Lingkungan runtime Python menyelesaikan hal ini dengan menampilkan pengecualian DeadlineExceededError dari google.appengine.runtime. Jika pengendali permintaan tidak menangkap pengecualian ini, seperti semua pengecualian yang tidak tertangkap, lingkungan runtime akan menampilkan error server HTTP 500 ke klien.

Pengendali permintaan dapat menangkap error ini untuk menyesuaikan respons. Lingkungan runtime memberikan pengendali permintaan waktu sedikit lebih banyak (kurang dari satu detik) setelah memunculkan pengecualian untuk menyiapkan respons khusus.

class TimerHandler(webapp2.RequestHandler):
    def get(self):
        from google.appengine.runtime import DeadlineExceededError

        try:
            time.sleep(70)
            self.response.write("Completed.")
        except DeadlineExceededError:
            self.response.clear()
            self.response.set_status(500)
            self.response.out.write("The request did not complete in time.")

Jika pengendali belum menampilkan respons atau memunculkan pengecualian pada batas waktu kedua, pengendali akan dihentikan dan respons error default akan ditampilkan.

Peringatan: AplikasiDeadlineExceededError dapat berpotensi diperoleh dari mana saja dalam program Anda, termasuk pemblokiran finally, sehingga dapat membuat program dalam keadaan tidak valid. Hal ini dapat menyebabkan deadlock atau error tidak terduga dalam kode thread (termasuk library threading bawaan), karena kunci mungkin tidak dilepas. Perhatikan bahwa (tidak seperti di Java) runtime mungkin tidak menghentikan proses, sehingga hal ini dapat menyebabkan masalah untuk permintaan berikutnya ke instance yang sama. Agar aman, Anda tidak boleh mengandalkan DeadlineExceededError, dan sebagai gantinya pastikan bahwa permintaan Anda selesai sebelum batas waktu.

Respons

App Engine memanggil skrip pengendali dengan Request dan menunggu skrip ditampilkan; semua data yang ditulis ke aliran output standar akan dikirim sebagai respons HTTP.

Ada batas ukuran yang berlaku untuk respons yang Anda buat, dan respons dapat diubah sebelum ditampilkan ke klien.

Untuk informasi selengkapnya, lihat Referensi respons permintaan.

Respons Streaming

App Engine tidak mendukung respons streaming ketika data dikirim dalam potongan inkremental ke klien saat permintaan sedang diproses. Semua data dari kode Anda dikumpulkan seperti yang dijelaskan di atas dan dikirim sebagai respons HTTP tunggal.

Kompresi respons

App Engine melakukan yang terbaik untuk menayangkan konten terkompresi (gzip) kepada klien yang mendukungnya. Untuk menentukan apakah konten harus dikompresi, App Engine melakukan hal berikut saat menerima permintaan:

1. Mengonfirmasi apakah klien dapat menerima respons terkompresi secara andal dengan melihat header Accept-Encoding dan User-Agent dalam permintaan. Pendekatan ini menghindari beberapa bug umum dengan konten yang dikompresi dengan gzip di browser populer.

2. Konfirmasi apakah kompresi konten sudah sesuai dengan melihat header Content-Type yang telah Anda konfigurasi untuk pengendali respons. Secara umum, kompresi sesuai untuk jenis konten berbasis teks, bukan jenis konten biner.

Perhatikan hal-hal berikut:

• Klien dapat memaksa jenis konten berbasis teks dikompresi dengan menetapkan header permintaan Accept-Encoding dan User-Agent ke gzip.

• Jika permintaan tidak menentukan gzip pada header Accept-Encoding, App Engine tidak akan mengompresi data respons.

• Google Frontend menyimpan respons dari file statis App Engine dan pengendali direktori ke dalam cache. Bergantung pada berbagai faktor, seperti jenis data respons yang disimpan dalam cache terlebih dahulu, header Vary mana yang telah Anda tentukan dalam respons, dan header mana yang disertakan dalam permintaan, klien dapat meminta data yang dikompresi tetapi menerima data yang tidak dikompresi, begitu juga sebaliknya. Untuk mengetahui informasi selengkapnya, lihat Penyimpanan respons dalam cache.

Penyimpanan dalam cache respons

Google Frontend, dan kemungkinan browser yang digunakan pengguna serta server proxy dengan cache perantara lainnya, akan menyimpan dalam cache respons aplikasi Anda seperti yang diinstruksikan oleh header penyimpanan cache standar yang Anda tentukan dalam respons. Anda dapat menentukan header respons ini melalui framework, langsung di kode, atau melalui pengendali direktori dan file statis App Engine.

Di Google Frontend, kunci cache adalah URL lengkap permintaan.

Menyimpan konten statis ke dalam cache

Untuk memastikan bahwa klien selalu menerima konten statis yang diperbarui segera setelah dipublikasikan, sebaiknya Anda menayangkan konten statis dari direktori berversi, seperti css/v1/styles.css. Google Frontend tidak akan memvalidasi cache (memeriksa konten yang diperbarui) hingga cache berakhir. Bahkan setelah masa berlaku cache berakhir, cache tidak akan diperbarui hingga konten di URL permintaan berubah.

Header respons berikut yang dapat Anda tetapkan di app.yaml memengaruhi cara dan waktu Google Frontend menyimpan konten dalam cache:

• Cache-Control harus disetel ke public agar Google Frontend dapat menyimpan konten dalam cache; tetapi juga dapat disimpan dalam cache oleh Google Frontend, kecuali jika Anda menentukan perintah Cache-Control private atau no-store. Jika Anda tidak menetapkan header ini di app.yaml, App Engine akan otomatis menambahkannya untuk semua respons yang ditangani oleh file statis atau pengendali direktori. Untuk mengetahui informasi selengkapnya, lihat Header yang ditambahkan atau diganti.

• Vary: Agar cache dapat menampilkan respons yang berbeda untuk URL berdasarkan header yang dikirim dalam permintaan, tentukan satu atau beberapa nilai berikut di header responds Vary: Accept danAccept-Encoding danOrigin , atauX-Origin

  Karena potensi kardinalitas yang tinggi, data untuk Vary lainnya tidak akan disimpan dalam cache.

  Contoh:

  1. Anda menentukan header respons berikut:

     Vary: Accept-Encoding

  2. Aplikasi Anda menerima permintaan yang berisi header Accept-Encoding: gzip. App Engine menampilkan respons terkompresi dan Google Frontend meng-cache versi data respons yang di-gzip. Semua permintaan berikutnya untuk URL ini yang berisi header Accept-Encoding: gzip akan menerima data hasil gzip dari cache hingga cache menjadi tidak valid (karena konten berubah setelah cache berakhir masa berlakunya).

  3. Aplikasi Anda akan menerima permintaan yang tidak berisi header Accept-Encoding. App Engine menampilkan respons yang tidak dikompresi dan Google Frontend akan meng-cache versi data respons yang tidak dikompresi. Semua permintaan berikutnya untuk URL ini yang tidak berisi header Accept-Encoding akan menerima data terkompresi dari cache hingga cache menjadi tidak valid.

  Jika Anda tidak menentukan header respons Vary, Google Frontend akan membuat satu entri cache untuk URL dan akan menggunakannya untuk semua permintaan, terlepas dari header dalam permintaan. Contoh:

  1. Anda tidak menentukan header respons Vary: Accept-Encoding.
  2. Permintaan berisi header Accept-Encoding: gzip, dan versi data respons yang di-gzip akan disimpan dalam cache.
  3. Permintaan kedua tidak berisi header Accept-Encoding: gzip. Namun, karena cache berisi versi data respons yang di-gzip, respons akan di-gzip meskipun klien meminta data yang tidak dikompresi.

Header dalam permintaan juga memengaruhi penyimpanan cache:

• Jika permintaan berisi header Authorization, konten tidak akan disimpan dalam cache oleh Google Frontend.

Masa berlaku cache

Secara default, header caching yang ditambahkan oleh file statis dan pengendali direktori App Engine ke respons memerintahkan klien dan proxy web seperti Google Frontend untuk menghentikan masa berlaku cache setelah 10 menit.

Setelah file dikirimkan dengan waktu habis masa berlaku tertentu, biasanya tidak mungkin untuk menghapusnya dari cache web-proxy, meskipun pengguna menghapus cache browsernya sendiri. Men-deploy ulang versi baru aplikasi tidak akan mereset cache apa pun. Oleh karena itu, jika Anda berencana mengubah file statis, file tersebut harus memiliki waktu habis masa berlaku yang singkat (kurang dari satu jam). Biasanya, waktu habis masa berlaku default 10 menit sudah sesuai.

Anda dapat mengubah masa berlaku default untuk semua pengendali direktori dan file statis dengan menentukan elemen default_expiration dalam file app.yaml Anda. Untuk menetapkan masa penyimpanan yang spesifik untuk masing-masing pengendali, tentukan elemen expiration dalam elemen pengendali di file app.yaml Anda.

Nilai yang Anda tentukan dalam waktu masa penyimpanan elemen akan digunakan untuk menetapkan header respons HTTP Cache-Control dan Expires.

Penyimpanan aplikasi dalam cache

Lingkungan runtime Python meng-cache modul yang diimpor saat memproses permintaan pada satu server web, serupa dengan cara aplikasi Python mandiri memuat modul hanya satu kali meskipun modul diimpor oleh beberapa file. Karena pengendali WSGI merupakan modul, pengendali tersebut disimpan dalam cache saat memproses permintaan. Skrip pengendali CGI hanya disimpan dalam cache jika menyediakan rutinitas main(); jika tidak, skrip pengendali CGI akan dimuat untuk setiap permintaan.

Penyimpanan aplikasi dalam cache memberikan manfaat signifikan dalam waktu respons. Kami merekomendasikan semua skrip pengendali CGI menggunakan rutinitas main(), seperti yang dijelaskan di bawah.

Impor disimpan dalam cache

Untuk efisiensi, server web menyimpan modul yang diimpor dalam memori dan tidak memuat ulang atau mengevaluasi ulang pada permintaan berikutnya ke aplikasi yang sama di server yang sama. Sebagian besar modul tidak menginisialisasi data global apa pun atau memiliki efek samping lain saat diimpor, sehingga penyimpanan cache tidak mengubah perilaku aplikasi.

Jika aplikasi Anda mengimpor modul yang bergantung pada modul yang dievaluasi untuk setiap permintaan, aplikasi tersebut harus mengakomodasi perilaku penyimpanan cache ini.

Menyimpan cache pengendali CGI

Anda dapat memberi tahu App Engine untuk menyimpan skrip pengendali CGI itu sendiri pada cache, selain modul yang diimpor. Jika skrip pengendali menentukan fungsi dengan nama main(), skrip dan lingkungan globalnya akan disimpan dalam cache seperti modul yang diimpor. Permintaan pertama untuk skrip di server web tertentu akan mengevaluasi skrip secara normal. Untuk permintaan berikutnya, App Engine memanggil fungsi main() di lingkungan yang disimpan dalam cache.

Untuk menyimpan skrip pengendali dalam cache, App Engine harus dapat memanggil main() tanpa argumen. Jika skrip pengendali tidak menentukan fungsi main(), atau fungsi main() memerlukan argumen (yang tidak memiliki default), App Engine akan memuat dan mengevaluasi seluruh skrip untuk setiap permintaan.

Menyimpan kode Python yang diurai dalam memori akan menghemat waktu dan memungkinkan respons yang lebih cepat. Menyimpan data ke dalam cache lingkungan global juga memiliki potensi manfaat lainnya:

• Ekspresi reguler yang dikompilasi. Semua ekspresi reguler diuraikan dan disimpan dalam bentuk yang dikompilasi. Anda dapat menyimpan ekspresi reguler yang dikompilasi dalam variabel global, lalu menggunakan penyimpanan aplikasi dalam cache untuk menggunakan kembali objek yang dikompilasi di antara permintaan.

• Objek GqlQuery. String kueri GQL diuraikan saat objek GqlQuery dibuat. Penggunaan kembali objek GqlQuery dengan binding parameter dan metode bind() lebih cepat daripada membangun ulang objek setiap saat. Anda dapat menyimpan objek GqlQuery dengan binding parameter untuk nilai dalam variabel global, lalu menggunakannya kembali dengan mengikat parameter value baru untuk setiap permintaan.

• File data dan konfigurasi Jika aplikasi Anda memuat dan mengurai data konfigurasi dari file, aplikasi dapat mempertahankan data yang diurai dalam memori untuk menghindari pemuatan ulang file pada setiap permintaan.

Skrip pengendali harus memanggil main() saat diimpor. App Engine memperkirakan dengan impor skrip akan memanggil main(), sehingga App Engine tidak akan memanggilnya saat memuat pengendali permintaan untuk pertama kalinya di server.

Catatan: Berhati-hatilah untuk tidak "membocorkan" informasi khusus pengguna saat memproses permintaan. Hindari variabel global kecuali jika penyimpanan cache diinginkan, dan selalu inisialisasi data khusus permintaan di dalam rutinitas main().

Penyimpanan aplikasi dalam cache dengan main() memberikan peningkatan yang signifikan dalam waktu respons pengendali CGI Anda. Kami merekomendasikannya untuk semua aplikasi yang menggunakan CGI.

Logging

Server web App Engine menangkap semua yang ditulis oleh skrip pengendali ke aliran output standar untuk respons terhadap permintaan web. App Engine juga merekam semua yang ditulis oleh skrip pengendali ke aliran data error standar, dan menyimpannya sebagai data log. Setiap permintaan akan diberi request_id, ID unik global berdasarkan waktu mulai permintaan. Data log untuk aplikasi Anda dapat dilihat di konsol Google Cloud menggunakan Cloud Logging

Lingkungan runtime App Engine Python menyertakan dukungan khusus untuk logging modul dari library standar Python guna memahami konsep logging seperti level log ("debug", "info", "warning", "error", "critical").

import logging

import webapp2


class MainPage(webapp2.RequestHandler):
    def get(self):
        logging.debug("This is a debug message")
        logging.info("This is an info message")
        logging.warning("This is a warning message")
        logging.error("This is an error message")
        logging.critical("This is a critical message")

        try:
            raise ValueError("This is a sample value error.")
        except ValueError:
            logging.exception("A example exception log.")

        self.response.out.write("Logging example.")


app = webapp2.WSGIApplication([("/", MainPage)], debug=True)

Lingkungan

Lingkungan eksekusi secara otomatis menetapkan beberapa variabel lingkungan; Anda dapat mengatur setelan lainnya di app.yaml. Dari variabel yang ditetapkan secara otomatis, beberapa bersifat khusus untuk App Engine, sementara yang lainnya merupakan bagian dari standar WSGI atau CGI. Kode Python dapat mengakses variabel ini menggunakan kamus os.environ.

Variabel lingkungan berikut ini khusus untuk App Engine:

• CURRENT_VERSION_ID: Versi utama dan minor dari aplikasi yang sedang berjalan, sebagai "X.Y". Nomor versi utama ("X") ditentukan dalam file app.yaml aplikasi. Nomor versi minor ("Y") ditetapkan secara otomatis saat setiap versi aplikasi diupload ke App Engine. Di server web pengembangan, versi minor selalu "1".

• AUTH_DOMAIN: Domain yang digunakan untuk mengautentikasi pengguna dengan User API. Aplikasi yang dihosting di appspot.com memiliki AUTH_DOMAIN dari gmail.com, dan menerima semua Akun Google. Aplikasi yang dihosting di domain khusus memiliki AUTH_DOMAIN yang sama dengan domain khusus.

• INSTANCE_ID: Berisi ID instance dari instance frontend yang menangani permintaan. ID berupa string hex (misalnya, 00c61b117c7f7fd0ce9e1325a04b8f0df30deaaf). Admin yang login dapat menggunakan ID di URL: https://INSTANCE_ID-dot-VERSION_ID-dot-SERVICE_ID-dot-PROJECT_ID.REGION_ID.r.appspot.com. Permintaan akan diarahkan ke instance frontend tertentu tersebut. Jika instance tidak dapat menangani permintaan, respons 503 akan langsung ditampilkan.

Variabel lingkungan berikut adalah bagian dari standar WSGI dan CGI, dengan perilaku khusus di App Engine:

• SERVER_SOFTWARE: Di server web pengembangan, nilai ini adalah "Development/X.Y", dengan "X.Y" sebagai versi runtime. Saat berjalan di App Engine, nilai ini adalah "Google App Engine/X.Y.Z".

Variabel lingkungan tambahan ditetapkan sesuai dengan standar WSGI atau CGI. Untuk informasi selengkapnya tentang variabel ini, lihat standar WSGI atau standar CGI, sesuai yang diperlukan.

Anda juga dapat menetapkan variabel lingkungan dalam file app.yaml:

env_variables:
  DJANGO_SETTINGS_MODULE: 'myapp.settings'

Pengendali permintaan webapp2 berikut menampilkan setiap variabel lingkungan yang terlihat oleh aplikasi di browser:

class PrintEnvironmentHandler(webapp2.RequestHandler):
    def get(self):
        self.response.headers["Content-Type"] = "text/plain"
        for key, value in os.environ.iteritems():
            self.response.out.write("{} = {}\n".format(key, value))

ID permintaan

Pada saat permintaan, Anda dapat menyimpan ID permintaan yang unik untuk permintaan tersebut. ID permintaan dapat digunakan nanti untuk mencari log permintaan tersebut di Cloud Logging.

Kode contoh berikut menunjukkan cara mendapatkan ID permintaan dalam konteks permintaan:

class RequestIdHandler(webapp2.RequestHandler):
    def get(self):
        self.response.headers["Content-Type"] = "text/plain"
        request_id = os.environ.get("REQUEST_LOG_ID")
        self.response.write("REQUEST_LOG_ID={}".format(request_id))

Memaksa koneksi HTTPS

Untuk alasan keamanan, semua aplikasi harus mendorong klien untuk terhubung melalui https. Untuk menginstruksikan browser agar lebih memilih https daripada http untuk halaman tertentu atau seluruh domain, tetapkan header Strict-Transport-Security dalam respons Anda. Contoh:

Strict-Transport-Security: max-age=31536000; includeSubDomains

Untuk menetapkan header ini untuk konten statis apa pun yang disalurkan oleh aplikasi, tambahkan header ke pengendali direktori dan file statis aplikasi Anda.

Untuk menetapkan header ini bagi respons yang dihasilkan dari kode Anda, gunakan library flask-talisman.

Perhatian: Klien yang sebelumnya telah menerima header akan menolak untuk terhubung jika https menjadi tidak berfungsi atau dinonaktifkan karena alasan apa pun. Untuk mempelajari lebih lanjut, baca Tips Praktis tentang HTTP Strict Transport Security.

Menangani pekerjaan latar belakang asinkron

Pekerjaan latar belakang adalah pekerjaan apa pun yang dilakukan aplikasi untuk sebuah permintaan setelah Anda mengirimkan respons HTTP. Hindari melakukan pekerjaan latar belakang di aplikasi Anda, dan tinjau kode untuk memastikan semua operasi asinkron selesai sebelum Anda mengirimkan respons.

Untuk tugas yang berjalan lama, sebaiknya gunakan Cloud Tasks. Dengan Cloud Tasks, permintaan HTTP berumur panjang dan menampilkan respons hanya setelah pekerjaan asinkron berakhir.

Peringatan: Menjalankan tugas latar belakang asinkron dapat mengakibatkan penagihan yang lebih tinggi. App Engine mungkin meningkatkan skala instance tambahan karena beban CPU yang tinggi, meskipun tidak ada permintaan aktif. Pengguna juga mungkin mengalami peningkatan latensi karena permintaan yang menunggu dalam antrean tertunda untuk instance yang tersedia.