Upakiaji wa PDF Kubwa Unapokataliwa: Kikomo cha 100 MiB cha Mwili wa Ombi na Hitilafu Inayokuelekeza Upande Usiofaa

PDF kubwa isiyopakiwa kwa kawaida si faili iliyoharibika. Mwili wa ombi umefikia kikomo cha kila ombi: 100 MiB, yaani baiti 104,857,600. Hupimwa kwa mwili wote, ukiwemo mipaka ya multipart na vichwa vya sehemu, na kiwango hicho hasa hupita wakati baiti moja zaidi hukataliwa.

Hitilafu inayorudi huelekeza mahali pengine. Vituo vya operesheni hurudisha 400 ambayo code yake ni bad_request na maelezo yanayosema sehemu ya multipart ilishindwa kusomwa, bila kutaja ukubwa popote. Mteja anayegawanya kwa code huiweka hii kama hitilafu ya kigezo na kwenda kukagua majina ya sehemu, wakati kile kinachopaswa kubadilishwa ni ukubwa wa faili.

100 MiB hiyo hiyo pia hutawala upande wa pili. Ombi lenye Idempotency-Key husoma jibu kwenye kumbukumbu kabla ya kulihifadhi, kwa kiwango kilekile, na likizidi mpigaji hupokea 500 wakati operesheni imekwisha kukamilika. Namba moja, namna mbili za kushindwa zilizo kinyume.

                     100 MiB = baiti 104,857,600 (kiwango hiki hasa hupita)
                                   |
                +------------------+------------------+
                |                                     |
   kinachoingia (mwili wa ombi)            kinachotoka (mwili wa jibu)
   mwili wote, ukiwemo mipaka ya           ni kwa Idempotency-Key pekee,
   multipart na vichwa vya sehemu;         kukosa kwenye hifadhi na
   operesheni na mtiririko mmoja           2xx kutoka juu
   kikizidi: 400 + bad_request             kikizidi: 500, hakuna hifadhi
   (maelezo: multipart ilishindwa kusomwa)

Kidokezo cha mchoro: kikomo kimoja, na pande zake mbili, kinachoingia na kinachotoka, hurudisha misimbo tofauti ya hali na matokeo yaliyo kinyume.

Kikomo huhesabu mwili wote wa ombi, ukiwemo mipaka

100 MiB hufunga mwili wa ombi moja, si ukubwa wa faili moja wala ukubwa baada ya kufunguliwa.

• Operesheni moja na mtiririko wa hatua nyingi hushiriki kiwango hicho. Kugawanya kazi kuwa hatua 10 ndani ya mwito mmoja wa /api/v1/pipeline hakubadilishi dari kuwa 1 GB; idadi ya hatua huathiri muda wa utekelezaji pekee.
• Kiwango cha mpaka chenyewe hupita: mwili wa ombi wa baiti 104,857,600 hupita, wa baiti 104,857,601 haupiti.
• Mwili hubeba vichwa vya kila sehemu na vitenganishi vya mipaka pamoja na baiti za faili, kwa hiyo nafasi inayobaki kwa faili moja ni chini ya 100 MiB kwa uhakika. Faili ya baiti 104,857,600 hasa hukataliwa.

Hoja hiyo ya mwisho ndiyo mahali mazoezi huteleza zaidi: curl -F huongeza mipaka kwa niaba yako, kwa hiyo kulinganisha ukubwa wa faili na mstari huo hakuwezi kamwe kutoa jibu sahihi.

Ukizidi kikomo hupata 400 na bad_request

Jibu la kuzidi kikomo halitumii 413, na halina neno lolote kuhusu ukubwa. Ijaribu tena kwa mwili unaozidi kwa baiti moja:

head -c 104857601 /dev/zero > /tmp/over.bin
curl -s -X POST "$API_BASE/api/v1/misc/compress-pdf" \
  -H "X-API-KEY: $API_KEY" \
  -F "fileInput=@/tmp/over.bin"

HTTP/1.1 400 Bad Request
content-type: application/problem+json

{ "code": "bad_request",
  "detail": "failed to read multipart field: Error parsing `multipart/form-data` request",
  "hint": "Fix request parameters or upload a valid PDF.",
  "status": 400,
  "title": "Bad Request",
  "type": "https://pdf123.xyz/developers/errors#bad_request" }

Mambo matatu ya kusoma pamoja:

• Hali ni 400. Kusoma mwili kulikoshindwa huainishwa hapa kama bad_request na bado hupita kupitia problem+json, kwa hiyo mteja aliyeandikwa kwa kanuni “kuzidi kikomo maana yake ni 413” huchukua tawi lisilo sahihi.
• code ni bad_request, kiingilio halisi katika jedwali la misimbo ya hitilafu. Haianguki kwenye tawi la jumla; hushiriki msimbo mmoja na jina la sehemu lililoandikwa vibaya au usimbaji wa multipart uliovunjika, na hakuna kitu katika jedwali hilo kinachohusu ukubwa.
• hint hukuambia pakia PDF halali. Faili uliyopakia kwa uwezekano mkubwa ni PDF halali iliyo kubwa kwa mamia machache ya baiti.

Kidokezo basi si msimbo wa hali bali idadi ya baiti za mwili: kwa 400 ambayo detail yake ina failed to read multipart field, pima ukubwa badala ya kurudi kupitia fomu.

413 hutokea pia kwenye tovuti hii, isipokuwa si kwenye vituo vya operesheni. Kila lango linalopokea upakiaji wa faili limepandishwa hadi 100 MiB, wakati vituo visivyopokea upakiaji bado huendeshwa kwa kikomo cha msingi cha mfumo wa HTTP (axum ya Rust) cha 2 MiB, ambapo mwili unaozidi hupata 413 na mstari mmoja wa maandishi matupu:

head -c 2097153 /dev/zero > /tmp/big.json
curl -s -w '\n%{http_code}\n' -X POST "$API_BASE/api/v1/auth/login" \
  -H 'Content-Type: application/json' \
  --data-binary @/tmp/big.json

Failed to buffer the request body: length limit exceeded
413

Ukweli mmoja, misimbo miwili ya hali na miili miwili ya majibu kutegemea kituo. Kuhamisha uzoefu wa upande mmoja hadi mwingine kutakupotosha.

Kushindwa kwingine kwa namba hiyo hiyo, upande wa kurudi

Ombi lenye Idempotency-Key huhifadhi jibu lake ili jaribio la pili liweze kulirudia. Kuhifadhi maana yake ni kusoma mwili wa jibu kwenye kumbukumbu kwanza, na usomaji huo hufungwa na 100 MiB hiyo hiyo, ingawa hukutana na masharti membamba zaidi:

1. Ombi lilikuwa na Idempotency-Key
2. Hifadhi ilikosa, kwa hiyo funguo hii ni mpya
3. Operesheni ya juu ilirudisha 2xx

Kushindwa hakuhifadhiwi na hupita moja kwa moja, kwa hiyo matokeo makubwa yenye mafanikio pekee hufikia kikomo hiki.

Kinachotokea hapo ndicho jambo la kukumbuka: hupata 500, na hakuna kinachoandikwa kwenye hifadhi. Operesheni imekwisha endeshwa, lakini mpigaji anaona kushindwa; kwa kuwa hakuna kilichohifadhiwa, jaribio la pili huendesha kitu kizima tena. Funguo ya idempotency ipo ili kuondoa kazi ya kurudiwa na hushindwa hasa inapohitajika zaidi, ikipamba kazi iliyokamilika kama hitilafu ya seva. Hifadhi hukaa kwenye kumbukumbu ya mchakato na haiandikwi kwenye diski kamwe, kwa hiyo kuanzisha upya huifuta; kwa maana yake ona Idempotency-Key: Majaribio Salama kwa Kazi za PDF.

100 MiB si mpangilio wa jukwaa unaoweza kubadilishwa

Kiwango hakiwezi kubadilishwa. Hakuna kigezo cha mazingira kinachokipandisha au kukishusha, kwa upande wowote; namba tofauti maana yake ni kubadilisha msimbo na kujenga picha upya. Ukitafuta kama mpangilio wa uenezaji, hutakipata.

Pia ni zaidi ya kipimo cha mgao. Baiti za mwili wa ombi husomwa kikamili kwenye kumbukumbu kabla ya kusindika, kwa hiyo kila upakiaji mkubwa unaofanyika kwa wakati mmoja hushikilia kiasi kinacholingana kando yake. Kupandisha dari maana yake ni kukubali kilele cha kumbukumbu cha juu pamoja nacho: namba hiyo pia ndiyo inayozuia ombi moja kusukuma mchakato chini.

Uenezaji wa kawaida wa kujihifadhi mwenyewe hauna wakala wa kinyume, na jukwaa halikagui ukubwa kabla ya kuwasilisha, kwa hiyo kukataliwa huko hutoka kwenye kikomo cha seva yenyewe. Ukiweka nginx mbele utagongana na nginx kwanza: client_max_body_size huruhusu 1 MiB pekee kwa msingi na hurudisha 413, umbo lililo karibu na lile la ulinganisho hapo juu na rahisi kudhaniwa kuwa kikomo kimoja.

Nini cha kufanya ukigongana nayo

Kuanzia cha bei nafuu:

1. Pima kabla ya kutuma. Linganisha idadi ya baiti za mwili wa ombi na 104,857,600 kabla ombi kutoka, na uache nafasi kwa mipaka. Hilo ni bora kuliko kusoma msimbo wa hali baadaye.
2. Bana faili hadi chini ya kikomo. Ukubwa wa skani hutoka hasa kwenye tabaka lake la picha, na kubana tena mara nyingi huondoa sehemu inayoonekana yake. Bana PDF huendeshwa kwenye kivinjari, bila hitaji la hati.
3. Gawanya kazi kwenye mwito kadhaa. Pale maudhui yanapogawanyika, yagawanye na uyatume kwa maombi machache: taabu kidogo kuliko kupandisha dari, na haiongezi kumbukumbu ambayo ombi moja hushikilia.
4. Badilisha kikomo kwa hitaji gumu la ombi moja pekee. Hiyo maana yake ni kubadilisha msimbo na kujenga upya, na kukubali gharama ya kumbukumbu ya sehemu iliyopita.

Kikomo hiki humtaka mteja aamue mapema

Hitilafu hizi mbili zote huelekeza kwenye hitimisho moja: kiwango cha 100 MiB kinapaswa kuhesabiwa na mteja kabla ya kutuma. Upande unaoingia, unajibiwa kwa bad_request, msimbo ambao hausemi kitu kuhusu ukubwa; upande unaotoka, unajibiwa kwa 500, unaoonekana kama hitilafu ya seva. Kuhesabu baiti kabla ombi kutoka ndiyo njia pekee ya hukumu isiyotegemea kile ujumbe wa hitilafu unachosema.