- शिप
- 23 सितंबर 2026 को 2:35 am बजे UTC
- लेखक
- Kamo
- Commit
- d1a8762
/डाउनलोड पूरी फाइल को बाइट में लोड किया [] ImageService.downloadDocument के माध्यम से पहले इसे सर्व करना; /bulk-download ने पूरे ZIP (या विलय PDF) को एक बाइट के रूप में बनाया [] जवाब देने से पहले दस्तावेज़PrepareService; अपलोड इस सेवा के ~1.4 जीबी के खिलाफ 3 जीबी तक चल रहा है हेप, और / बल्क-डाउनलोड की 100-आईडी कैप में इसके पीछे कोई आकार सीमा नहीं थी - 100 अनकैप्ड दस्तावेज़ इसके पीछे हो सकते हैं एक अनुरोध में सैकड़ों गीगाबाइट्स के लिए पूछें। buildZip ने Img.fileName को सीधे लिखा कोई स्वच्छता के साथ एक ZipEntry, इसलिए एक दस्तावेज़ का नाम बदलकर कुछ ऐसी चीज़ों के नाम पर रखा गया है। ************* (fileName) उपयोगकर्ता-नियंत्रित — मुफ्त पाठ, के माध्यम से बदल गया है /update/filename/{imgId}) ने एक संग्रह का निर्माण किया जिसका प्रवेश, एक चिमटा द्वारा खोला गया, जो नहीं करता है स्वयं ज़िप-पर्ची के खिलाफ सुरक्षा करते हैं, लक्ष्य निर्देशिका के बाहर लिखते हैं जिस पर ओएस कर रहा है निकालने। - /डाउनलोड अब MinIOStorageservice.openrange + स्ट्रीमिंगResponseBody के माध्यम से धाराओं, बिल्कुल पसंद /स्ट्रीम पहले से ही पूरी फाइल को बफर करने के बजाय किया। (Drops Imageservice.downloadDocument) Dl-first/dl-last बहीखाता साइड इफेक्ट — grep द्वारा मृत की पुष्टि की: जावा बैकएंड में कुछ भी नहीं कभी पढ़ा जाता है Img.dlFirstDate/dlastDate, केवल कभी उन्हें लिखते हैं। अलग ImgLogDownload ऑडिट रिकॉर्डDownloadEvent के माध्यम से पंक्ति, जिसे डाउनलोड-हिस्ट्री पैनल द्वारा वापस पढ़ा गया है, अपरिवर्तित है। - / थोक-डाउनलोड dedupes ने 100-आईडी टोपी और प्रति-item काम से पहले ids का अनुरोध किया। - /bulk-download एक बार चयनित दस्तावेजों के संयुक्त Img.fileSize पास करने से इनकार कर दिया 500 MB, मर्ज/zip के प्रयास के बजाय और एक OOM जोखिम से इनकार कर दिया, चुपचाप नहीं अनुवादित, क्योंकि पूर्णता एक थोक एक्सपोर्ट का बिंदु है। - buildZip अपने अंतिम पथ खंड (दोनों / और \ दोनों पर विभाजित) के लिए हर प्रविष्टि नाम को पवित्र करता है एक्सट्रैक्टर एक OS पर हो सकता है जो सर्वर को नियंत्रित नहीं करता है), ज़िप-पर्ची अंतराल को बंद कर देता है। डीएन नहीं, एक ज्ञात अंतर के रूप में सूचना दी: buildZip/mergePdfs अभी भी एक बाइट के रूप में अपने परिणाम का निर्माण [] इसे सीधे HTTP प्रतिक्रिया पर स्ट्रीम करने के बजाय जवाब देने से पहले - 500 एमबी कैप अब सीमा है कि एक ज्ञात छत (असीमित से नीचे), लेकिन यह समाप्त नहीं हुआ है। उन्हें कनवर्ट करना एक कॉलर-supplied आउटपुटस्ट्रीम में लिखने के लिए भी / bulk-download स्ट्रीम दे देंगे; deferred क्योंकि यह दस्तावेज़ में बदलावPrepareService के सार्वजनिक हस्ताक्षर, तीन मौजूदा परीक्षण फ़ाइलों में लहर (वर्तमान में मोक्स बाइट [] रिटर्निंग विधियों को ठूंठें), एक मध्यम गंभीरता के लिए, पहले से ही कैप्ड शेष - एक जानबूझकर गुंजाइश कॉल, एक नजर नहीं। नया परीक्षण: ************* (7 मामलों के लिए sanitizeZipEntryName) और तीन मामलों ImagingControllerMediaAssocTest (streaming-not-buffering, id dedupe, आकार टोपी) में जोड़ा गया। Mutation-checked: ImagingController.java को अपने पूर्व-फिक्स राज्य में फिर से बदल देता है तीन नए नए नियंत्रक मामले लाल; reverting sanitizeZipEntryName को `वापसी नाम;` 7 ज़िप-पर्ची में से 5 बदल जाता है मामलों में लाल (6th, पहले से ही सुरक्षित साधारण फ़ाइल नाम, ठीक से unaffected है। पूर्ण सूट: 741 परीक्षण हरे रंग (731; +10 नया)।.