2010-01-07
2010-01-06
What is the maximum length of a URL?
2006-10-13: Although the specification of the HTTP protocol does not specify any maximum length, practical limits are imposed by web browser and server software.
Microsoft Internet Explorer (Browser)
Microsoft states that the maximum length of a URL in Internet Explorer is 2,083 characters, with no more than 2,048 characters in the path portion of the URL. In my tests, attempts to use URLs longer than this produced a clear error message in Internet Explorer.
Firefox (Browser)
After 65,536 characters, the location bar no longer displays the URL in Windows Firefox 1.5.x. However, longer URLs will work. I stopped testing after 100,000 characters.
Safari (Browser)
At least 80,000 characters will work. I stopped testing after 80,000 characters.
Opera (Browser)
At least 190,000 characters will work. I stopped testing after 190,000 characters. Opera 9 for Windows continued to display a fully editable, copyable and pasteable URL in the location bar even at 190,000 characters.
Apache (Server)
My early attempts to measure the maximum URL length in web browsers bumped into a server URL length limit of approximately 4,000 characters, after which Apache produces a "413 Entity Too Large" error. I used the current up to date Apache build found in Red Hat Enterprise Linux 4. The official Apache documentation only mentions an 8,192-byte limit on an individual field in a request.
Microsoft Internet Information Server
The default limit is 16,384 characters (yes, Microsoft's web server accepts longer URLs than Microsoft's web browser). This is configurable.
Perl HTTP::Daemon (Server)
Up to 8,000 bytes will work. Those constructing web application servers with Perl's HTTP::Daemon module will encounter a 16,384 byte limit on the combined size of all HTTP request headers. This does not include POST-method form data, file uploads, etc., but it does include the URL. In practice this resulted in a 413 error when a URL was significantly longer than 8,000 characters. This limitation can be easily removed. Look for all occurrences of 16x1024 in Daemon.pm and replace them with a larger value. Of course, this does increase your exposure to denial of service attacks.
Recommendations
Extremely long URLs are usually a mistake. URLs over 2,000 characters will not work in the most popular web browser. Don't use them if you intend your site to work for the majority of Internet users.
When you wish to submit a form containing many fields, which would otherwise produce a very long URL, the standard solution is to use the POST method rather than the GET method:
...
The form fields are then transmitted as part of the HTTP transaction body, not as part of the URL, and are not subject to the URL length limit. Short-lived information should not be stored in URLs.
As a rule of thumb, if a piece of information isn't needed to regenerate the same page as a result of returning to a favorite or bookmark, then it doesn't belong in the URL.
The Bookmark Problem
In very rare cases, it may be useful to keep a large amount of "state" information in a URL. For instance, users of a map-navigating website might wish to add the currently displayed map to their "bookmarks" or "favorites" list and return later. If you must do this and your URLs are approaching 2,000 characters in length, keep your representation of the information as compact as you can, squeezing out as much "air" as possible. If your field names take up too much space, use a fixed field order instead. Squeeze out any field that doesn't really need to be bookmarked. And avoid large decimal numbers - use only as much accuracy as you must, and consider a base-64 representation using letters and digits (I didn't say this was easy).
In extreme cases, consider using the gzip algorithm to compress your pretty but excessively long URL. Then reencode that binary data in base64 using only characters that are legal in URLs. This can yield a 3-4x space gain, at the cost of some CPU time when you unzip the URL again on the next visit. Again, I never said it was easy!
An alternative is to store the state information in a file or a database. Then you can store only the identifier needed to look up that information again in the URL. The disadvantage here is that you will have many state files or database records. Some of which might be linked to on websites run by others. One solution to this problem is to delete the state files or database records for the URLs that have not been revisited after a certain amount of time.
"What happens if the URL is too long for the server?"
What exactly happens if a browser that supports very long URLs (such as Firefox) submits a long URL to a web server that does not support very long URLs (such as a standard build of Apache)?
The answer: nothing dramatic. Apache responds with a "413 Entity Too Large" error, and the request fails.
This response is preferable to cutting the URL short, because the results of cutting the URL short are unpredictable. What would that mean to the web application? It varies. So it's better for the request to fail.
In the bad old days, some web servers and web browsers failed to truncate or ignore long URLs, resulting in dangerous "buffer overflow" situations. These could be used to insert executable code where it didn't belong... resulting in a security hole that could be exploited to do bad things.
These days, the major browsers and servers are secure against such obvious attacks - although more subtle security flaws are often discovered (and, usually, promptly fixed).
While it's true that modern servers are themselves well-secured against long URLs, there are still badly written CGI programs out there. Those who write CGI programs in C and other low-level languages must take responsibility for paying close attention to potential buffer overflows. The CGIC library can help with this.
In any case, if you're a web developer and you're still asking this question, then you probably haven't paid attention to my advice about how to avoid the problem completely.
資料引用：
http://www.boutell.com/newfaq/misc/urllength.html
Microsoft Internet Explorer (Browser)
Microsoft states that the maximum length of a URL in Internet Explorer is 2,083 characters, with no more than 2,048 characters in the path portion of the URL. In my tests, attempts to use URLs longer than this produced a clear error message in Internet Explorer.
Firefox (Browser)
After 65,536 characters, the location bar no longer displays the URL in Windows Firefox 1.5.x. However, longer URLs will work. I stopped testing after 100,000 characters.
Safari (Browser)
At least 80,000 characters will work. I stopped testing after 80,000 characters.
Opera (Browser)
At least 190,000 characters will work. I stopped testing after 190,000 characters. Opera 9 for Windows continued to display a fully editable, copyable and pasteable URL in the location bar even at 190,000 characters.
Apache (Server)
My early attempts to measure the maximum URL length in web browsers bumped into a server URL length limit of approximately 4,000 characters, after which Apache produces a "413 Entity Too Large" error. I used the current up to date Apache build found in Red Hat Enterprise Linux 4. The official Apache documentation only mentions an 8,192-byte limit on an individual field in a request.
Microsoft Internet Information Server
The default limit is 16,384 characters (yes, Microsoft's web server accepts longer URLs than Microsoft's web browser). This is configurable.
Perl HTTP::Daemon (Server)
Up to 8,000 bytes will work. Those constructing web application servers with Perl's HTTP::Daemon module will encounter a 16,384 byte limit on the combined size of all HTTP request headers. This does not include POST-method form data, file uploads, etc., but it does include the URL. In practice this resulted in a 413 error when a URL was significantly longer than 8,000 characters. This limitation can be easily removed. Look for all occurrences of 16x1024 in Daemon.pm and replace them with a larger value. Of course, this does increase your exposure to denial of service attacks.
Recommendations
Extremely long URLs are usually a mistake. URLs over 2,000 characters will not work in the most popular web browser. Don't use them if you intend your site to work for the majority of Internet users.
When you wish to submit a form containing many fields, which would otherwise produce a very long URL, the standard solution is to use the POST method rather than the GET method:
...
The form fields are then transmitted as part of the HTTP transaction body, not as part of the URL, and are not subject to the URL length limit. Short-lived information should not be stored in URLs.
As a rule of thumb, if a piece of information isn't needed to regenerate the same page as a result of returning to a favorite or bookmark, then it doesn't belong in the URL.
The Bookmark Problem
In very rare cases, it may be useful to keep a large amount of "state" information in a URL. For instance, users of a map-navigating website might wish to add the currently displayed map to their "bookmarks" or "favorites" list and return later. If you must do this and your URLs are approaching 2,000 characters in length, keep your representation of the information as compact as you can, squeezing out as much "air" as possible. If your field names take up too much space, use a fixed field order instead. Squeeze out any field that doesn't really need to be bookmarked. And avoid large decimal numbers - use only as much accuracy as you must, and consider a base-64 representation using letters and digits (I didn't say this was easy).
In extreme cases, consider using the gzip algorithm to compress your pretty but excessively long URL. Then reencode that binary data in base64 using only characters that are legal in URLs. This can yield a 3-4x space gain, at the cost of some CPU time when you unzip the URL again on the next visit. Again, I never said it was easy!
An alternative is to store the state information in a file or a database. Then you can store only the identifier needed to look up that information again in the URL. The disadvantage here is that you will have many state files or database records. Some of which might be linked to on websites run by others. One solution to this problem is to delete the state files or database records for the URLs that have not been revisited after a certain amount of time.
"What happens if the URL is too long for the server?"
What exactly happens if a browser that supports very long URLs (such as Firefox) submits a long URL to a web server that does not support very long URLs (such as a standard build of Apache)?
The answer: nothing dramatic. Apache responds with a "413 Entity Too Large" error, and the request fails.
This response is preferable to cutting the URL short, because the results of cutting the URL short are unpredictable. What would that mean to the web application? It varies. So it's better for the request to fail.
In the bad old days, some web servers and web browsers failed to truncate or ignore long URLs, resulting in dangerous "buffer overflow" situations. These could be used to insert executable code where it didn't belong... resulting in a security hole that could be exploited to do bad things.
These days, the major browsers and servers are secure against such obvious attacks - although more subtle security flaws are often discovered (and, usually, promptly fixed).
While it's true that modern servers are themselves well-secured against long URLs, there are still badly written CGI programs out there. Those who write CGI programs in C and other low-level languages must take responsibility for paying close attention to potential buffer overflows. The CGIC library can help with this.
In any case, if you're a web developer and you're still asking this question, then you probably haven't paid attention to my advice about how to avoid the problem completely.
資料引用：
http://www.boutell.com/newfaq/misc/urllength.html
2009-09-28
Microsoft websitespark
WebSiteSpark provides software licenses that you can use for three years at no cost. Once enrolled, you can download and immediately use the following software from Microsoft:
•3 licenses of Visual Studio 2008 Professional Edition
•1 license of Expression Studio 3 (which includes Expression Blend, Sketchflow, and Web)
•2 licenses of Expression Web 3
•4 processor licenses of Windows Web Server 2008 R2
•4 processor licenses of SQL Server 2008 Web Edition
•DotNetPanel control panel (enabling easy remote/hosted management of your servers)
The Windows Server and SQL Server licenses are for you to do both development and production work. Also, the production licenses can be leveraged in a couple of different ways. You can do 1 production server with 4 processors or 4 servers with 1 processor each. These servers can also be either dedicated hardware or virtualized offerings. If you want, you can throw the licenses on your own server with the “self-hosted” model or you can enroll with one of the hosters that have signed up as a Network Partner. As a Network Partner, they will pass the savings of the licenses on to you and only charge you for the infrastructure work. You can find all of the hosting network partners on the WebsiteSpark page.
資料來源
http://www.joshholmes.com/blog/2009/09/24/AnnouncingTheWebsiteSparkProgram.aspx
微軟websitespark網站
http://www.microsoft.com/web/websitespark/
•3 licenses of Visual Studio 2008 Professional Edition
•1 license of Expression Studio 3 (which includes Expression Blend, Sketchflow, and Web)
•2 licenses of Expression Web 3
•4 processor licenses of Windows Web Server 2008 R2
•4 processor licenses of SQL Server 2008 Web Edition
•DotNetPanel control panel (enabling easy remote/hosted management of your servers)
The Windows Server and SQL Server licenses are for you to do both development and production work. Also, the production licenses can be leveraged in a couple of different ways. You can do 1 production server with 4 processors or 4 servers with 1 processor each. These servers can also be either dedicated hardware or virtualized offerings. If you want, you can throw the licenses on your own server with the “self-hosted” model or you can enroll with one of the hosters that have signed up as a Network Partner. As a Network Partner, they will pass the savings of the licenses on to you and only charge you for the infrastructure work. You can find all of the hosting network partners on the WebsiteSpark page.
資料來源
http://www.joshholmes.com/blog/2009/09/24/AnnouncingTheWebsiteSparkProgram.aspx
微軟websitespark網站
http://www.microsoft.com/web/websitespark/
2009-09-26
Open Source Free Antivirus for Windows 2003
ClamWin Free Antivirus
ClamWin is a Free Antivirus program for Microsoft Windows 98/Me/2000/XP/2003 and Vista.
ClamWin Free Antivirus comes with an easy installer and open source code. You may download and use it absolutely free of charge. It features:
ClamWin is a Free Antivirus program for Microsoft Windows 98/Me/2000/XP/2003 and Vista.
- High detection rates for viruses and spyware;
- Scanning Scheduler;
- Automatic downloads of regularly updated Virus Database.
- Standalone virus scanner and right-click menu integration to Microsoft Windows Explorer;
- Addin to Microsoft Outlook to remove virus-infected attachments automatically.
2009-09-16
未來啟示錄SP1 Online 看到在地化的力量!!
第一次在電視上看到這個遊戲的宣傳短片，感覺還蠻不錯的
《未來啟示錄》遊戲宣傳影片 - 遊戲基地
後來某天..........
看到了台灣在地化版本的廣告，我笑了....深植我心...忘都忘不了
跟大家分享一下
SP1未來啟示錄TV廣告 台語版+字幕
《未來啟示錄》遊戲宣傳影片 - 遊戲基地
後來某天..........
看到了台灣在地化版本的廣告，我笑了....深植我心...忘都忘不了
跟大家分享一下
SP1未來啟示錄TV廣告 台語版+字幕
2009-09-09
SQL Server log 大爆炸
前一星期有個同事因為SQL Server 2008 Transcation log 檔案太大，導致SQL Server無法運作，他做了以下的動作，將SQL Server的執行程序停止，手動刪除log實體檔案，再次啟動SQL Server的程序，完蛋了.......叫不起來
後來依照以下的方式把資料庫給救回來囉~~紀錄一下
假設資料庫名稱為OhMyGod
1. 停止SQL Server, 將原mdf檔移走
2. 開啟SQL Server, 建立新的OhMyGod資料庫.
3. 停止SQL Server
4. 將損壞的mdf覆蓋回新建的mdf檔,並刪除新建的log檔
5. 開啟SQL Server
3. 設定OhMyGod資料庫狀態為EMERGENCY:
ALTER DATABASE OhMyGod SET EMERGENCY
4. 設定OhMyGod資料庫模式為"單一使用者":
sp_dboption 'OhMyGod', 'single user', 'true'
5. 檢查指定資料庫中所有物件的配置、結構和邏輯完整性:
DBCC CHECKDB (OhMyGod, REPAIR_ALLOW_DATA_LOSS)
6. 還原OhMyGod資料庫模式:
sp_dboption 'OhMyGod', 'single user', 'false'
7. 設定OhMyGod資料庫狀態為
ONLINE:ALTER DATABASE OhMyGod SET ONLINE
完成以上動作，資料庫救回來了，萬幸萬幸~~
後來依照以下的方式把資料庫給救回來囉~~紀錄一下
假設資料庫名稱為OhMyGod
1. 停止SQL Server, 將原mdf檔移走
2. 開啟SQL Server, 建立新的OhMyGod資料庫.
3. 停止SQL Server
4. 將損壞的mdf覆蓋回新建的mdf檔,並刪除新建的log檔
5. 開啟SQL Server
3. 設定OhMyGod資料庫狀態為EMERGENCY:
ALTER DATABASE OhMyGod SET EMERGENCY
4. 設定OhMyGod資料庫模式為"單一使用者":
sp_dboption 'OhMyGod', 'single user', 'true'
5. 檢查指定資料庫中所有物件的配置、結構和邏輯完整性:
DBCC CHECKDB (OhMyGod, REPAIR_ALLOW_DATA_LOSS)
6. 還原OhMyGod資料庫模式:
sp_dboption 'OhMyGod', 'single user', 'false'
7. 設定OhMyGod資料庫狀態為
ONLINE:ALTER DATABASE OhMyGod SET ONLINE
完成以上動作，資料庫救回來了，萬幸萬幸~~
2009-05-22
Hinet Domain Name 申請
跟Hinet 申請了一個 imusic.idv.tw 的Domain 給 imusic音樂才藝教室 用。
設定DNS的時候發現還真陽春的功能，頂多只能設定三組 domain name <-> IP，真的很陽春
後來發現 PCHome 也有提供網域申請的服務，附加的DNS服務就好用多了....失敗
一樣的價錢PcHome多了
DNS代管功能：
除了設定 DNS 自管外，DNS 代管包含有 A 記錄 + MX + CNAME + 轉址功能，共 15 組
過一年後來改用 PCHome的服務吧~
設定DNS的時候發現還真陽春的功能，頂多只能設定三組 domain name <-> IP，真的很陽春
後來發現 PCHome 也有提供網域申請的服務，附加的DNS服務就好用多了....失敗
一樣的價錢PcHome多了
DNS代管功能：
除了設定 DNS 自管外，DNS 代管包含有 A 記錄 + MX + CNAME + 轉址功能，共 15 組
過一年後來改用 PCHome的服務吧~
訂閱：
文章 (Atom)