อยา่กจะ post ไว้เผื่อมีใครเจอปัญหาแบบผม มีระบบที่ผมทำใช้ตัวนึงใช้ Flex แล้วก็ติดต่อกับ server ผ่าน remote object format ข้อมูลเป็น AMF (Action message format) โดยใช้ library SabreAMF (php) ใช้งานได้ดีมาตลอดในทุก browser แต่มาวันนึง IE8 ออกมาผมก็พบว่าโปรแกรมผมใช้ไม่ได้ (โอ้วพระเจ้า) ผมเลยพยายามหาสาเหตุผมว่าทำไม IE8 กับ Remote Object Channel ทีฺ่ีใช้จึงมีปัญหาทั้งใน Vista หรือ XP ก็เป็น ทำให้ผมพบเพื่อน ที่เป็นเหมือนกันหลายคนใน bugs.adobe.com, forum flex จนในที่สุดเมื่อ สามวันก่อนก็มีคนของ adobe มาไขข้อข้องใจ aglosban ผมจะยกมาเลยนะครับ ที่เค้า อธิบาย
Hi. Adobe is currently investigating this problem and we have reported the issue to Microsoft to get help from them to resolve it. I will tell you what we know about the problem so far and give you some potential workarounds.
We haven’t been able to determine at this point what OS and software configuration causes the problem. Users have reported having this problem with IE 8 on Vista and XP machines. We have done testing internally on Vista and XP machines with IE 8 that did not have this problem. We have an XP machine with IE 8 that does have the problem, but the problem only reproduces when running under one user account which makes us think that the problem is related to some software installed under that user account or settings (possibly browser or caching related but maybe not) applied to that user account.
It looks like the problem is related to how IE does Mime type resolution and how it manages its cache. IE is saving responses to HTTP Post requests to disk when the HTTP request URL does not have a file extension. For example when using a polling channel in BlazeDS, the URL to the endpoint on the server might look like this.
IE stores the responses from HTTP Post requests to the endpoint URL to disk in numbered files based on the last part of the URL. So, based on the above URL, you could see a number of files on disk like the following that contain the responses sent back for the HTTP Post requests.
To see these files you’ll need to look at what IE is saving to its temporary internet files using a disk utility or browsing the temporary internet files from a command prompt as the files are hidden by the OS.
On machines that have the problem, it appears that IE at some point is unable to write the response to disk and this results in the NetConnection.Call.Failed error. It looks like IE numbers these files 1 – 11 and on machines that have the problem, the problem only seems to occur after IE has written the 11th file and goes to write the next file to disk. Clearing the temporary internet files in IE does not appear to remove these files. Removing the files by manually deleting them or using a cleanup utility such as CCleaner will temporarily resolve the problem until after the 11th file has been written to disk at which point the problem will start occurring again.
Here are some potential workarounds for this problem. We are still hoping to get a resolution from Microsoft. We have not done thorough testing to certify that any of these workarounds entirely resolve the problem and don’t introduce any new issues, which is to say that before you use any of these workarounds in a production environment you should do testing to make sure that the workaround resolves the issue for you and doesn’t cause any problems for your application. Most of these workarounds involve preventing IE from writing the HTTP Post responses to disk. We tried setting additional no cache and no store headers on the HTTP response but this did not prevent IE from writing the responses to disk. This likely has to do with how IE does Mime type resolution but it’s unfortunate that IE doesn’t seem to respect the no cache and no store headers in this case.
1) Using HTTPS instead of HTTP seemed to resolve the problem during our testing. It’s likely that the caching behavior in IE is different when HTTPS is being used which is why the problem would occur over HTTP and not over HTTPS.
2) Adding a file extension to the end of the endpoint URL in the services-config.xml file seemed to resolve the problem during our testing. Also, looking at what IE was writing to disk we did not see the HTTP Post responses written to disk when the endpoint URL had a file extension. Here is an example of an endpoint URL modified to have a file extension.
It’s likely that files with an extension are treated differently by IE when it does its Mime type resolution and makes a determination on whether to cache the file which would account for the difference in behavior when the URL didn’t have a file extension and when it did have a file extension.
3) Using an HTTPEndpoint (AMFX) instead of an AMFEndpoint (AMF) seems to resolve the problem. The content type for AMFX messages is text based while AMF messages are binary which would explain why IE treats the two message types differently.
4) When you compile your application, set the target version to Flash Player 10. SWFs compiled for FP9 and FP10 execute differently even if both are run in Flash Player 10. Setting the target version when compiling the application to FP10 seemed to work around the problem.
5) Modifying the BlazeDS source to set the content type for AMF messages to something text based such as text/xml instead of application/x-amf seemed to resolve the problem. Based on my reading about IE mime type resolution this probably does not fool IE into thinking the content is text based but does seem to change the caching behavior in such a way that it avoids the problem.
Update: One thing I forgot to mention for workaround number 5 is that there is at least one problem this workaround introduces that makes it not a very good solution. Third party programs that work with AMF such as some HTTP sniffers and test automation tools will likely not be able to work with the AMF messages if you change the content type. It’s also not clear how changing the content type would would affect how applications run in other browsers.
จากที่ผมทดสอบมาวิธีที่ใช้งานได้คือการเปลี่ยน target version เป็น 10 จากเดิมที่เป็น 9 ตา่มข้อที่ 4