يعتبر العنصر Uploadify.com من أشهر العناصر المستخدمة في تحميل الملفات بطريقة غير متزامنة علماً أنه يتوفر منه نسختين الأولى فلاش Flash والثانية HTML5. هذه المقالة تتحدث عن تجربة استخدام نسخة الفلاش من Uploadify مع خادم الـ UAG (Unified Access Gateway) الخاص بشركة مايكروسوفت حيث واجهتنا مشكلة ظهور الخطأ التالية:
500 internal server error
عند محاولة تحميل ملفات بغض النظر عن نوعها وأيضاً بغض النظر عن لغة البرمجة المستخدمة. وبعد محاولات كثيرة وبحث تم الاستعانة بشركة مايكروسوفت لحل هذه المشكلة وقد كان جواب مهندس مايكروسوفت كما يلي:
So Multipart/form-data is something that UAG does not support and also according to RFC http://www.w3.org/Protocols/rfc1341/7_2_Multipart.html
The CRLF preceding the encapsulation line is considered part of the boundary so that it is possible to have a part that does not end with a CRLF (line break). Body parts that must be considered to end with line breaks, therefore, should have two CRLFs preceding the encapsulation line, the first of which is part of the preceding body part, and the second of which is part of the encapsulation boundary.
The requirement that the encapsulation boundary begins with a CRLF implies that the body of a multipart entity must itself begin with a CRLF before the first encapsulation line -- that is, if the "preamble" area is not used, the entity headers must be followed by TWO CRLFs. This is indeed how such entities should be composed. A tolerant mail reading program, however, may interpret a body of type multipart that begins with an encapsulation line NOT initiated by a CRLF as also being an encapsulation boundary, but a compliant mail sending program must not generate such entities.
Encapsulation boundaries must not appear within the encapsulations, and must be no longer than 70 characters, not counting the two leading hyphens.
The encapsulation boundary following the last body part is a distinguished delimiter that indicates that no further body parts will follow. Such a delimiter is identical to the previous delimiters, with the addition of two more hyphens at the end of the line:
--gc0p4Jq0M2Yt08jU534c0p—
More info on page 30 : http://www.ietf.org/rfc/rfc1341.txt
أي أنه من الواضح وجود نقص في المعلومات التي يرسلها Uploadify (Flash Version) وعلى اعتبار أنه لا يمكن التعديل على شيفرة الفلاش فقد كانت نصيحة مهندس مايكروسوفت هي إيقاف عملية فحص المعلومات المرسلة من قبل العنصر Uploadify وبذلك يتم حل المشكلة. وبالفعل تم اتباع الخطوات التالية باستخدام UGA لإيقاف عملية فحص البيانات المرسلة من قبل Uploadify:
http://technet.microsoft.com/en-us/library/dd278134.aspx
علماً أنه في الخطوة رقم 5 يجب استخدام اسم الصفحة التي يُرسل إليها Uploadify البيانات وفي حالتنا كانت كما يلي:
./Uploadify\.ashx.*
ملاحظة: قد لا تظهر هذه المشكلة عند رفع ملف أكبر من 3 ميغا والسبب غير معروف أيضاً وقد يعود لآلية تعامل العنصر Uploadify مع الملفات وآلية رفعها.
شكر خاص للمهندس ياسين رحال لمساعدته في هذه المشكلة.
