標籤: iis

分類
系統技術

再談URL長度上限

先來看一下之前寫的:

由 browser 的上限來看是 2083, 而由 apache / iis 來看則是 8190 / 4096 兩個等級.

不過無論如何, 這個 url 上限的討論是個很熱門的問題:

https://stackoverflow.com/questions/417142/what-is-the-maximum-length-of-a-url-in-different-browsers

除了 RFC / Browser / Web Server 外, 還多提出了 CDN (其中的 status code 414 (414 URI Too Long, https://tools.ietf.org/html/rfc7231#section-6.5.12) 就是在描述這個:

這個很重要, 因為 CDN 是轉遞內容的重要功能, 不過看起來長度也都放得很寬.

再來看個別瀏覽器利用測試的方式來查看長度:

Browser Address bar document.location or anchor tag
Chrome 32779 >64k
Android 2192 >64k
Firefox >64k >64k
Safari >64k >64k
IE11 2047 5120
Edge 16 2047 1024

也都有相當的長度.

不過由以上來看, 還是得保守地使用約在 2000 bytes 長度的 url 較為保險.

 

分類
系統技術

Apache與IIS Web Sever URL長度上限

之前有查過 browser 的 url 上限, 可以參考這篇: https://diary.tw/archives/455 , 當時是為了調查 referer 的 url 上限, 進而找出 browser 的 url 上限.

那 web server 上的上限呢? 在 Apache 下有個 LimitRequestLine 的設置, 可以設定 URL 上限, 參考: http://httpd.apache.org/docs/2.2/mod/core.html#limitrequestline

而該值預設為 8190 也就是大約在 8k 左右.

在 IIS 則是利用參數 requestLimits 中的參數, MaxUrl, 預設是 4096, 參考這篇: http://www.iis.net/configreference/system.webserver/security/requestfiltering/requestlimits

這樣看起來基本上都比 Browser 長得多.

分類
.net

Rewrite造成的403問題

之前介紹過這個軟體: ISAPIREWRITE https://diary.tw/archives/260

在 iis 下, 使用這個 isapirewrite 時, 要特別注意應用程式集區問題, 若是 rewrite 前後 application 使用不同的 app pool 時, 會發生 403 拒絕存取.

簡單地說, rewrite 的前後, 使用相同的 app pool 時, 這個問題就不會發生, 但有時為了增進效能及除錯應用, 或是獨立 web application, 切到不同的 app pool.

例如:

RewriteCond ^/test/([a-z0-9]+) /test/url.aspx?uid=$1 [I, CL, L]

都是在 /test 下的這個 app pool, 可以正常工作, 若是以下的 rewrite:

RewriteCond ^/test2/([a-z0-9]+) /test/url.aspx?uid=$1 [I, CL, L]

若是 /test2 和 /test 使用不同 app pool (應用程式集區) 時, 就會發生 403 的拒絕存取.

這是今天在除錯時發現的一個重大問題. 若有不明的 403 在 rewrite 上時, 可以往這個方向檢查看看!

IIS 7 BitRate Throttling 模組

在以往的 iis 限流功能上, 一直是以整個 web 站台的總流量來進行限流管理, 當然這也算是一種限流管理方式, 但在現今這種影音應用的環境下, 相信如何能有效應用頻寬並進一步來節省成本, 相信是很重要的課題.

以往要在 web server 上做流量管理, 最理想的方式是做 per connection 的限流, 這個功能在 iis 上並沒有提供, 不過在 apache 上有個 mod_bandwidth 模組可以做到, 他的原理就是進行單一 connection 的流量限制, 在這種狀況下, 就可以有效地管理每一個 connection 的流量, 簡單地說, 若是放在 web 上的影音內容, bitrate 是 300kbps 的話, 我們可以利用 mod_bandwidth 將流量限制在 330kbps左右, 讓這些影音內容能在邊下載邊看的速度下進行觀賞, 這樣最重要的是對 server 端能節省頻寬. 因為一般人也不見得會整個看完, 若是用很快的速度讓使用者下載, 事實上會蠻浪費頻寬的.

然而隨著在 iis 7 上提供 BitRate Throttling模組功能時, 這些狀況就會改觀了, 根據技術文件提到, 這個模組可以根據媒體檔案內容的 mime-type 及 bitrate header進行流量限制, 並提供了前面多少時間(幾秒)的快速下載, 之後根據 bitrate進行限流, 看起來彈性及功能遠比 apache 的 mod_bandwidth 模組有更大的彈性及好處.

實務上, 這將會是一個相當有效節省頻寬的一個管理方式, 這個部分相信對未來影音應用的普及下, 將會發揮更大的作用哦.

這篇介紹了如何偵測 bit-rate的方式及設置方式:
http://learn.iis.net/page.aspx/149/bit-rate-throttling-extensibility-walkthrough/

這篇介紹如何安裝這個模組:
http://learn.iis.net/page.aspx/147/bit-rate-throttling-setup-walkthrough/

這篇介紹如何設定及驗證:
http://learn.iis.net/page.aspx/148/bit-rate-throttling-configuration-walkthrough/

其他相關閱讀:

這篇有實作後的流量比較結果:

http://blogs.msdn.com/jijia/archive/2007/12/30/iis-7-0-bandwidth-throttling.aspx

分類
.net

在Windows2003 64Bit下執行ASP.NET2.0應用程式

由於要測試 windows 2003 64bit OS 下的效能, 必須將 ASP.NET 2.0的應用程式部署上去.

但擔心會有相容性的問題, 於是開始找相關的資料. 其實也都沒有找到. 相關的資料僅有在 x64 上的 iis 若要跑 64bit 模式, 就一定得用 asp.net 2.0 才行, 若是 asp.net 1.1 的話, 就僅能跑在 32bit 模式下. 後來直接將 compile 好的 asp.net 2.0 程式, 部署上去在 x64 下的 iis, 結果可以順利執行, 真是方便, 沒有相容性的問題.

應該是 asp.net build 好的 msil code 並沒有含 32/64相依的程式碼, 而要到 runtime 時, 依 runtime 的環境, 來執行 msil code, 所以沒有相容性的問題. 至於為什麼 1.1 要在 32bit 模式下執行, 想必是因為在 x64 os 上, 並沒有 64bit 的 1.1 runtime isapi, 所以只能在 32bit 模式下執行囉.

以上是升級作業系統至 x64 時的一個小插曲, asp.net 2.0 是不會有什麼問題的啦…

分類
懶得分類

有趣的rewrite

之前在設定 apache rewrite 感覺很有趣, 可以做很多應用, 加上功能強大, 幾乎可以將網址改的很炫很讚, 後來也玩了一下 ISAPI_Rewrite (網址: http://www.isapirewrite.com/), HELICON提供的 ISAPI_Rewrite 功能也類似, 免費版本 ISAPI_Rewrite Lite 可以使用於該 iis 上全部的網站, 所以若要設定個別的虛擬主機的 rewrite rule 時, 就要花錢買 ISAPI_Rewrite FULL. 當然 apache 的 rewrite module 是完全免費的囉.

閱讀全文 “有趣的rewrite”