又發生了這樣的錯誤。表象總是那麼撲朔迷離。

有客戶說文件上傳服務不能用了。錯誤提示的是服務器錯誤。但是其他機器可以，說明服務本身並沒有大問題，或者說錯誤的發生，源於客戶端環境的不一樣。得出結論並沒有什麼不妥。

關鍵在於客戶端什麼環境有問題？這是一個非常有意思的過程。

先簡單說明一下，文件上傳服務發布了一個地址 http://myServer/upload.aspx, 在Post的時候，將本地的文件數據提交上來即可。支持斷點續傳，所以每個文件都會產生一個唯一的ID。

為了搞明白整個Post的過程中，哪裡不一樣，我們動用了利器HttpAnalysis。這個工具可以跟蹤所有的Http請求過程。通過對比，發現成功上傳文件的客戶端和失敗的客戶端的請求頭沒有差別。我們嘗試用成功上傳文件的客戶端的請求數據，在失敗的客戶機器上模擬，發現竟然也沒問題。那問題，就必然出現在數據提交上了。

認真對比了一下，發現數據還真有問題。原來，這個上傳文件的服務，需要獲取文件的創建日期，當時作者的實現，就是使用了DateToStr (Delphi) 轉換成為了字符串。然後服務器再依據字符串進行轉換。但是大家知道，DateToStr，是依據本地的短日期設置格式來轉換的，如果本地設置和服務器設置不一致，就有可能不能反向解析。

我們打開上傳文件失敗的機器的時間格式設置一看，原來他的格式是這樣的：“yyyy-mm-dd-星期”,後面多了一個星期，服務器自然識別不了，好了，既然知道錯誤了，就好改了。

總結的時候，我們發現其實這個問題早就發生過，為什麼還會出現呢？應該有靜態分析工具，去將這些經驗遺留下來，以後就不會再因為人員的變化而遺忘了。

後話：或許有人要問，直接調試服務器不更簡單？是的，但是由於服務器並不是我們自己編寫的，我們只是借用別人的現成的服務，所以很多方面還有遷就別人的設計。

本文出自 “韓小明的博客” 博客，請務必保留此出處http://xiammy.blog.51cto.com/3301816/605100