FlickrProxy #1 - Overview

問題與答案 (FAQ)

Q&A 類別 A: 概念理解類

A-Q1: 什麼是 FlickrProxy？

• A簡: 一個以伺服端透明代理實現自動上傳並轉址圖片的機制，減輕頻寬負擔與綁定
• A詳: FlickrProxy 是一種伺服端的透明代理機制，攔截網站對圖檔的請求，在執行階段檢查該圖是否需要上傳至 Flickr。若尚未上傳且符合策略，會自動透過 API 上傳並將使用者重新導向至 Flickr 的圖片 URL；若不需要，則直接回應本機檔案內容。其特色是不綁定特定用戶端工具或帳號、可隨時停用或更換後端服務，並保留完整的本地檔案以利備份。適合頻寬受限的小型網站，透過外部服務分擔流量。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: A-Q3, A-Q4, B-Q1

A-Q2: 為何小型網站常遇到頻寬瓶頸？

• A簡: ADSL 上傳頻寬有限，圖片與多媒體流量集中於伺服端，造成載入延遲
• A詳: 多數自架小型網站使用 ADSL 或家用級上傳頻寬，單一連線上傳量低且共用壅塞。圖片與多媒體檔體積較大，當讀者同時瀏覽時請求集中在伺服端，導致回應時間上升與連線數耗盡。若流量無緩衝機制或外部卸載，容易在尖峰期發生載入緩慢或逾時。藉由將靜態資源代理至外部圖床（如 Flickr），可把大量下行流量轉移，改善用戶體驗與主機負載。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: A-Q1, B-Q7, D-Q6

A-Q3: 什麼是客戶端外掛（如 WLW Flickr 插件）方案？

• A簡: 在發文端完成上傳、取連結與產生 HTML 片段，貼入文章內容使用
• A詳: 客戶端外掛（如 Windows Live Writer 的 Flickr 插件）在編輯與發文時執行一連串操作：將圖片上傳至外部服務、取得遠端連結、產生嵌入用的 HTML，並貼回文章。其優點是發文後即定稿、讀者端無額外延遲；缺點是發文時即鎖定服務與帳號，後續批次更換服務、改帳號或脫離該編輯器會變得困難，且舊文資源難以統一遷移或回收。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: A-Q5, A-Q4, B-Q3

A-Q4: 什麼是伺服端透明代理的解法？

• A簡: 由伺服端在請求時代為處理上傳與轉址，對用戶與作者透明
• A詳: 伺服端透明代理是在讀者請求內容時，由伺服端攔截並判斷是否需把資源外移；若需外移，則於執行階段完成上傳並回應轉址，否則回應本地資源。對作者與讀者皆盡量不改變使用方式：作者照常放圖到網站，讀者瀏覽時自動使用最合適的來源。優勢是易於隨時切換後端服務、停用功能與集中控管規則，弱點是首次請求多一步處理，可能增加延遲。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: A-Q1, B-Q4, B-Q1

A-Q5: FlickrProxy 與 WLW 外掛的差異是什麼？

• A簡: 前者伺服端動態決策可切換服務，後者客戶端發文即定稿綁帳號
• A詳: WLW 外掛在發文時完成上傳與嵌入，優點是瀏覽時無額外處理、效能最佳；但服務與連結被鎖死，不易後續統一更換。FlickrProxy 則在瀏覽時決策，能統一套用規則、隨時改用其他服務或停用，且保留本地檔案便於備份與還原。其代價是首次命中需要判斷與上傳，效能略遜但換得更高的彈性與可維運性。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: A-Q3, A-Q4, B-Q5

A-Q6: 為什麼選擇伺服端方案而非客戶端外掛？

• A簡: 降低綁定、集中治理、可回溯備份，並能隨時關閉或更換服務
• A詳: 伺服端方案讓決策與流程集中在系統端，不依賴特定編輯器或帳號；當外部服務更換、政策改變或需停用時，只要改伺服端設定即可。保留一份完整本地檔案，備份與災復更簡單；舊文亦可在瀏覽時逐步遷移。雖有性能成本，但透過快取、延遲上傳與背景處理可緩解。總體而言，維運與長期彈性優勢明顯。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q5, B-Q7, B-Q13

A-Q7: 什麼是 ASP.NET 的 HttpHandler？

• A簡: 一種可攔截特定路徑或副檔名請求並自訂回應的元件
• A詳: HttpHandler 是 ASP.NET 管線中的擴充點，負責處理特定資源類型（如 .jpg、.zip）的 HTTP 請求。透過在 web.config 註冊對應副檔名，就能由自訂類別接手處理流程，例如讀取檔案、改寫、快取、轉址或代理外部資源。FlickrProxy 即以 HttpHandler 攔截圖片請求，實現判斷、上傳與轉址邏輯，達到透明代理的效果。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: B-Q4, C-Q1

A-Q8: 什麼是 Run Time 動態檢查與轉向？

• A簡: 在請求當下即時判斷策略並決定直接回應或轉址外部
• A詳: Run Time 動態檢查指的是不預先離線處理，而在使用者請求來到伺服器時即時判斷：檔案是否已上傳？是否需要外移？若需上傳則先完成上傳，再回應 302/307 轉址至外部 URL；若無需外移或上傳失敗且允許回退，則回應本地檔案內容。此模式避免發文時綁定，並可逐步遷移舊內容，代價是首訪成本與併發控制要妥善設計。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q1, B-Q2, B-Q5

A-Q9: 什麼是 POC（Proof of Concept）？

• A簡: 小規模驗證技術可行性的原型，降低風險與錯誤方向
• A詳: POC 是以最小可行原型驗證關鍵技術或假設的過程，重點在可行性與風險識別而非完整度。在 FlickrProxy 的背景下，POC 旨在證明以 HttpHandler 攔截並把頁面中的圖片代理到另一目錄或外部服務是可行的，開發者可用 Fiddler 等工具觀察請求是否正確改寫或轉址，以此再決定投入完整實作與架構化。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: B-Q14, C-Q10

A-Q10: 什麼是 Provider 架構？

• A簡: 以抽象介面封裝後端差異，讓服務可插拔、可替換
• A詳: Provider 架構透過定義一組抽象契約（介面或基底類別），把具體服務（如 Flickr、YouTube、SkyDrive）差異封裝在各自的實作中，呼叫端只面向統一介面。好處是可插拔與易於替換，便於在不同服務間切換或新增媒體類型；測試也可注入模擬實作。FlickrProxy 以 Provider 抽象圖片與影片等媒體後端，整合既有的 HttpHandler。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q6, C-Q8, C-Q9

A-Q11: 何謂透明代理（Transparent Proxy）？

• A簡: 對使用者與作者行為不變，代理在中間無縫代辦工作
• A詳: 透明代理指在不改變客戶端與內容作者操作模式下，由中間層自動代辦資源取得、轉換或轉發等工作。對使用者來說仍是請求原位址；對作者而言仍是正常發布內容。FlickrProxy 以透明代理移轉圖片流量至外部圖床，降低頻寬負擔，同時保留本地資源。與反向代理相比，重點在動態決策與策略性外移而非單純轉發。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q15, A-Q4

A-Q12: FlickrProxy 的核心價值是什麼？

• A簡: 降載與去綁定兼顧，保留本地副本並可隨時更換服務
• A詳: FlickrProxy 以伺服端整合與透明代理達到三目標：其一，將圖片流量外移，紓解小型站台頻寬；其二，避免在發文時綁定特定帳號或平台，保留日後替換彈性；其三，持續保有完整本地檔與連結控制，便於備份、還原與治理。雖然放大了伺服端的設計複雜度與執行開銷，但換得長期維運與風險控管上的主導權。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: A-Q1, A-Q6, B-Q7

A-Q13: FlickrProxy 可支援哪些媒體？

• A簡: 以圖片為主，透過 Provider 擴充至影片與壓縮檔等
• A詳: 初始重點在圖片代理至 Flickr；藉由 Provider 抽象，可延伸支援影片（如轉連至 YouTube 或改通訊協定至 RTSP）與壓縮檔（如 ZIP 虛擬為資料夾或上傳至雲端儲存，例如 SkyDrive/OneDrive）。不同媒體的流程與風險各異，擴充時需依其 API、大小與合規限制設計相應策略與回退機制。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q10, C-Q8, C-Q9

A-Q14: 何謂自動上傳與重新導向？

• A簡: 首次命中自動上傳至外部，再以 302/307 導向其公開連結
• A詳: 自動上傳是指在伺服端接到圖片請求時，若策略判定需外移且尚未上傳，便即時呼叫外部服務 API 完成上傳；上傳成功後，回應 HTTP 302（或 307）將瀏覽器導向外部圖片 URL。後續請求可直接導向遠端或使用快取。本機仍保留檔案以備回退或停用此功能時能直接服務內容。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: B-Q3, B-Q5

A-Q15: 效能與彈性的取捨為何？

• A簡: 首訪增加延遲換取長期可替換、集中治理與備援能力
• A詳: 伺服端方案在首次命中需判斷、可能上傳與記錄對應，帶來延遲與 CPU/IO 開銷；相較之下，客戶端外掛在發文時已定稿，瀏覽階段更快。若站點重視長期可維運性（換服務、備份、回退）、集中政策與逐步遷移舊文，FlickrProxy 的彈性優勢更顯著。可透過快取、背景上傳、併發控制與熔斷策略改善效能。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q7, D-Q6, A-Q5

Q&A 類別 B: 技術原理類

B-Q1: FlickrProxy 的整體運作流程如何？

• A簡: 攔截請求→決策→必要時上傳→記錄映射→回應本地或轉址
• A詳: 原理為在 ASP.NET 管線以 HttpHandler 接管圖片請求。流程：1) 解析請求路徑與參數；2) 查詢映射表判斷是否已有遠端 URL；3) 若無且策略需要外移，進行認證後呼叫 Flickr 上傳 API；4) 取得遠端 URL，更新映射儲存；5) 回應：若已上傳則 302/307 轉址，否則直接串流本地檔；6) 設定快取標頭與記錄監控。核心組件包含 Handler、策略判斷、上傳客戶端、映射儲存與紀錄。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q1, C-Q2, C-Q1

B-Q2: 伺服端如何判斷圖片是否需要上傳？

• A簡: 透過策略：大小、路徑、標記、Header 或白名單黑名單規則
• A詳: 決策層會綜合多條件：檔案大小/類型、位於特定目錄、檔名標記、查詢字串開關、作者註記、站台模式（開/關/只新檔）、快取命中與映射存在與否。亦可配置白名單（必外移）與黑名單（永本地）規則，或用標頭/旗標觸發跳過上傳。策略應可設定並可 A/B 驗證，以避免過度外移造成成本或延遲。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q8, C-Q6, B-Q7

B-Q3: 自動上傳至 Flickr 的機制是什麼？

• A簡: 以 API 金鑰與權杖認證，HTTP 上傳檔案並取得公開 URL
• A詳: 伺服端先持有 Flickr API Key/Secret，透過 OAuth 流程取得長期權杖。上傳時以多段表單（multipart/form-data）傳送影像與必要參數（標題、隱私設定等），成功回應含 photo id。之後再以 API 查詢該照片可公開存取的 URL（或按規則組合），並記錄映射。本流程需處理重試、節流與錯誤碼解析，避免重複上傳與併發衝突。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: C-Q3, A-Q14, D-Q1

B-Q4: ASP.NET 如何攔截圖檔請求？

• A簡: 透過 web.config 註冊 HttpHandler，指向自訂類別處理
• A詳: 在 system.webServer/handlers（IIS7+）或 system.web/httpHandlers 註冊對應副檔名（.jpg, .png 等）至自訂 Handler 類別。IIS 會將符合的請求交由該類別的 ProcessRequest 執行，內部即可讀取 QueryString、路徑、身分資訊、檔案串流並執行自定邏輯。需注意靜態檔案模組優先順序與繞過快取設定。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: A-Q7, C-Q2, C-Q1

B-Q5: 重新導向至 Flickr 圖片的原理是什麼？

• A簡: 回應 302/307 與 Location 標頭，引導瀏覽器改請求外部 URL
• A詳: 上傳成功後，伺服端以 302 Found 或 307 Temporary Redirect 設定 Location=遠端圖片 URL，瀏覽器依規範自動重新發出 GET 請求至 Flickr。選擇 302/307 取決於是否需保留方法與語義；對圖片 GET 皆可。亦可設定 Cache-Control 與 ETag，讓後續命中減少往返。需避免形成重導迴圈並正確處理相對/絕對網址。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: A-Q5, D-Q2, A-Q14

B-Q6: Provider 模式的技術設計如何？

• A簡: 定義媒體介面與操作契約，注入不同後端實作以替換
• A詳: 建立 IMediaProvider 介面，定義上傳、查詢、刪除、組合 URL 與權限設定等方法；圖片對應 FlickrProvider，影片對應 YouTubeProvider，壓縮檔對應 CloudStorageProvider。核心流程依賴抽象介面，不直接耦合具體 SDK。透過 DI 容器或工廠依設定選擇實作，並在跨媒體共享共通策略、快取與重試框架。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q10, C-Q8, C-Q9

B-Q7: FlickrProxy 如何處理快取與效能？

• A簡: 首訪決策，上傳結果與映射快取；回應與轉址設適當標頭
• A詳: 對映射查詢可用記憶體快取/分散式快取；對上傳結果與遠端 URL 設 TTL 與失效策略。回應端針對本地檔加 ETag/Last-Modified；對轉址則利用長 Cache-Control 或短 TTL 視遠端穩定度調整。首訪上傳可背景化或以佇列處理，避免同步延遲；添加節流、熔斷與降級（回應本地檔）以保障高峰穩定。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: C-Q7, D-Q6, A-Q15

B-Q8: 如何保持本機檔案與遠端的一致性與備份？

• A簡: 本地為真實來源，記錄映射並定期校驗、備份與還原流程
• A詳: 將本地檔視為真實來源（Source of Truth），對應遠端 URL 僅為加速管道。維護映射表（路徑→遠端 URL、photo id、狀態），並定期校驗有效性（404/403 掃描）。備份包含檔案與映射資料庫；還原時可自動重建映射或切換為本地服務模式。停止服務時直接回應本地檔即可不中斷。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: D-Q10, B-Q9, A-Q12

B-Q9: 如何記錄本地檔與遠端 URL 的映射？

• A簡: 以資料庫或檔案存儲路徑、photo id、URL、狀態與時間
• A詳: 建議以 SQLite/SQL Server 儲存映射：Key=本地標識（路徑、雜湊），欄位含遠端 photo id、URL、隱私、建立/更新時間、上傳狀態與錯誤碼。提供唯一索引避免重複上傳；加入版本欄位便於併發控制；對熱門鍵加快取。亦可用 JSON 檔於小型站快速落地，但需注意鎖定與損毀風險。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: C-Q4, D-Q5, B-Q1

B-Q10: 如何支援其他媒體如 YouTube 或雲端儲存？

• A簡: 以 Provider 抽象，依各 API 設計上傳、轉址與權限流程
• A詳: 針對影片建立 VideoProvider，封裝 YouTube 上傳與取得播放連結，或僅進行 HTTP→RTSP 的協定轉換。壓縮檔則用 CloudStorageProvider 上傳至 SkyDrive/OneDrive/S3 等並生成分享連結。核心流程沿用：攔截→決策→上傳→映射→回應（直出或轉址），惟需應對各平台配額、大小限制與隱私控制差異。
• 難度: 高級
• 學習階段: 進階
• 關聯概念: A-Q13, C-Q8, C-Q9

B-Q11: 安全與權限有哪些考量？

• A簡: 安全存放 API 憑證、最小授權、權杖輪替與存取控制
• A詳: 將 API Key/Secret 與 OAuth 權杖置於安全儲存（如機密管理器/加密設定），採最小授權與分環境配置。實作權杖輪替與撤銷流程，記錄審計軌跡。對外回應避免洩露內部路徑與錯誤詳情；對上傳速率與來源限制加防濫用機制。內部介面需驗身分與授權，避免任意觸發批次上傳或刪除。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: D-Q4, C-Q3, B-Q6

B-Q12: 失敗重試與容錯機制如何設計？

• A簡: 指數退避重試、冪等保證、熔斷降級與併發去重
• A詳: 對暫時性錯誤實作指數退避重試，設最大次數與超時；確保上傳操作冪等（以檔案雜湊與鎖避免重複上傳）。遠端故障時啟用熔斷，暫時降級為本地回應；恢復後再嘗試背景上傳。對同一資源請求進行併發去重（單航線）避免放大風暴。所有錯誤與決策需記錄以便追蹤。
• 難度: 高級
• 學習階段: 進階
• 關聯概念: D-Q1, D-Q6, B-Q7

B-Q13: 如何做到隨時關閉此功能？

• A簡: 設置全域開關與策略模式，關閉時直接回應本地檔案
• A詳: 以設定旗標（appSettings/Feature Flag）控制總開關與策略級別（全關、只新檔、全開）。在 Handler 首段即讀取開關，關閉時略過決策與上傳，直接回應本地內容。可加入動態熱切換（不重啟）與分流比例，配合監控觀察影響。關閉時仍保留既有映射以利後續恢復。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: C-Q5, D-Q7, A-Q6

B-Q14: POC 如何驗證技巧可行？

• A簡: 建立最小 Handler，代理與轉址少量資源，觀察請求
• A詳: 製作最小可用 Handler，攔截單一路徑或目錄下的圖片，簡化策略為「一律轉至另一目標或目錄」，以 Fiddler/瀏覽器開發者工具觀察請求鏈、轉址狀態與回應標頭。確認核心步驟（攔截、改寫、轉址）可用後，再逐步引入上傳 API、映射存儲與快取。POC 重點在風險揭露與路徑趨近，而非完備性。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: A-Q9, C-Q10, B-Q1

B-Q15: 透明代理與反向代理有何差異？

• A簡: 透明代理強調決策與轉換，反向代理偏向轉發與快取
• A詳: 反向代理多作為前端閘道，負責負載平衡、TLS 與快取，對後端服務轉發請求；透明代理則在中間層動態決策是否外移、上傳或轉換資源，可能更改資源最終落點。FlickrProxy 既有代理特性亦含內容外移與轉址邏輯，屬應用層透明代理。兩者可互補：前者前置，後者在應用內部執行。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: A-Q11, A-Q4

Q&A 類別 C: 實作應用類

C-Q1: 如何在 ASP.NET 建立基本的 FlickrProxy HttpHandler？

• A簡: 建立 IHttpHandler 類別，於 ProcessRequest 實作決策與回應
• A詳:
  • 實作步驟: 建立 class FlickrProxyHandler : IHttpHandler，注入策略與上傳服務；在 ProcessRequest 中讀取路徑→查映射→決策→上傳→回應。
  • 程式碼: public class FlickrProxyHandler : IHttpHandler { public void ProcessRequest(HttpContext ctx) { var path = ctx.Request.Path; var map = MapStore.Find(path); if (map == null && Policy.ShouldOffload(path)) { var url = FlickrClient.Upload(path); MapStore.Save(path, url); ctx.Response.Redirect(url, false); return; } if (map != null) { ctx.Response.Redirect(map.Url, false); return; } ctx.Response.WriteFile(ctx.Server.MapPath(path)); } public bool IsReusable => true; }
  • 注意: 控制例外、避免重複上傳、設 Cache 標頭。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q4, B-Q1, C-Q2

C-Q2: 如何設定 web.config 攔截圖片請求？

• A簡: 在 handlers 註冊副檔名對應自訂 Handler 類別與動詞
• A詳:
  • 步驟: 將 .jpg/.png/.gif 綁定至 FlickrProxyHandler。
  • 設定:
  • 注意: 確認模組順序、避免與靜態檔案處理衝突；於開發環境先限目錄測試。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: B-Q4, C-Q1

C-Q3: 如何整合 Flickr API 進行上傳？

• A簡: 使用 OAuth 授權與 multipart 上傳，回得 photo id 與公開連結
• A詳:
  • 步驟: 申請 API Key/Secret→完成 OAuth→以 multipart/form-data 上傳。
  • 程式碼（概念）: var resp = await Flickr.UploadAsync(new UploadParams { FilePath = path, Title = title, IsPublic = true }); var url = await Flickr.GetPhotoUrlAsync(resp.PhotoId);
  • 注意: 安全儲存憑證、處理重試與節流、對超大檔分片或壓縮。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q3, B-Q11, D-Q1

C-Q4: 如何設計映射儲存（SQLite/JSON）？

• A簡: 以唯一鍵存本地路徑與雜湊，存放遠端 URL 與狀態欄位
• A詳:
  • 步驟: 建表 Columns: LocalKey, Hash, RemoteId, RemoteUrl, Status, CreatedAt, UpdatedAt, Error。
  • SQL 片段: CREATE TABLE Map(LocalKey TEXT PRIMARY KEY, Hash TEXT, RemoteId TEXT, RemoteUrl TEXT, Status INT, CreatedAt DATETIME, UpdatedAt DATETIME);
  • 注意: 加唯一索引避免重複上傳；以交易更新；小站可用 JSON，但需檔鎖與備份。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q9, D-Q5

C-Q5: 如何加上功能開關（Feature Toggle）？

• A簡: 於設定檔加入旗標，Handler 讀取後決定是否啟用代理
• A詳:
  • 步驟: appSettings 加 FlickrProxy.Enabled 與 Mode（Off/On/NewOnly）。
  • 程式碼: var mode = Config.Get(“FlickrProxy.Mode”,”On”); if (mode==”Off”) { ServeLocal(ctx); return; }
  • 注意: 支援熱更新（IOptionsMonitor/檔案監看）；記錄切換審計；設計分流比例以灰度發布。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: B-Q13, D-Q7

C-Q6: 如何加入白名單/黑名單規則？

• A簡: 以路徑、大小與標記組合規則，策略層判斷是否外移
• A詳:
  • 步驟: 設定 Whitelist/Blacklist（前綴/Regex/目錄）、MaxSizeKB、AllowTypes。
  • 程式碼: if (Blacklist.Any(m=>m.IsMatch(path))) return false; if (Whitelist.Any(m=>m.IsMatch(path))) return true; return size > MinSize && AllowTypes.Contains(ext);
  • 注意: 以單元測試覆蓋規則；加入緊急跳過標頭 X-Proxy-Bypass。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q2, B-Q7

C-Q7: 如何實作快取與 ETag/Last-Modified？

• A簡: 計算檔案雜湊與修改時間，回應條件式請求減少傳輸
• A詳:
  • 步驟: 本地服務時以 SHA-1 作 ETag，File.GetLastWriteTime 作 Last-Modified；若 If-None-Match/If-Modified-Since 命中則回 304。
  • 程式碼: var etag = Hash(file); if (ctx.Request.Headers[“If-None-Match”]==etag){NotModified();}
  • 注意: 轉址回應也可附帶 Cache-Control；對遠端 URL 可在映射層設 TTL 快取。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q7, D-Q6

C-Q8: 如何擴充支援 YouTube 的 Provider？

• A簡: 新增 VideoProvider，封裝上傳與取得播放連結流程
• A詳:
  • 步驟: 定義 IVideoProvider.Upload/GetUrl；實作 YouTubeProvider（OAuth、quota、分類）；在 Handler 依副檔名選擇 Provider。
  • 程式碼: var url = YouTubeProvider.Upload(path, meta); MapStore.Save(path,url);
  • 注意: 影片檔大，建議背景佇列與上傳進度；必要時先以 HTTP→RTSP 轉連做過渡。
• 難度: 高級
• 學習階段: 進階
• 關聯概念: B-Q10, A-Q13

C-Q9: 如何將 ZIP 虛擬化為資料夾並改存雲端？

• A簡: 以虛擬檔案系統列出 ZIP 內容，按需上傳至雲端儲存
• A詳:
  • 步驟: 使用 ZIP 探勘庫（如 System.IO.Compression）將壓縮內容映射為虛擬路徑；攔截檔案請求時從 ZIP 串流或先上傳至雲端（OneDrive/S3）並回分享連結。
  • 程式碼: using var z=ZipFile.OpenRead(zip); var e=z.GetEntry(p); e.Open().CopyTo(resp);
  • 注意: 大檔分段、權限與一次性 URL；維護映射與快取。
• 難度: 高級
• 學習階段: 進階
• 關聯概念: B-Q10, B-Q9

C-Q10: 如何監控與記錄代理行為？

• A簡: 使用日誌與外部工具（Fiddler）追蹤轉址、耗時與錯誤
• A詳:
  • 步驟: 在關鍵節點（決策、上傳、轉址、回退）記錄結構化日誌；建立儀表（成功率、首訪延遲、上傳耗時、錯誤碼）。用 Fiddler/瀏覽器 Network 檢視 302/Location 與快取命中。
  • 程式碼: _logger.LogInfo(“upload”, new{path, ms, status});
  • 注意: 打點抽樣、避免敏感資訊外洩；設告警門檻。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q14, D-Q1, D-Q6

Q&A 類別 D: 問題解決類

D-Q1: 遇到上傳 Flickr 失敗怎麼辦？

• A簡: 檢查權杖與配額，重試退避，必要時回退本地直接服務
• A詳:
  • 症狀: 首訪延遲後轉為本地、頻繁錯誤碼、上傳逾時。
  • 原因: 權杖失效、API 配額用盡、網路不穩、檔案超限或格式不符。
  • 解法: 驗證 OAuth、檢查配額與錯誤碼；實施指數退避重試與熔斷；對特定錯誤（4xx）標記黑名單；暫時回退本地回應。
  • 預防: 監控配額與告警、健康檢查、背景批次與大小限制。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q3, B-Q12, B-Q11

D-Q2: 發生重新導向循環該怎麼處理？

• A簡: 確認 Location 正確與排除 Handler 自吞，加入防迴圈保護
• A詳:
  • 症狀: 瀏覽器顯示過多轉址或最終 310/ERR_TOO_MANY_REDIRECTS。
  • 原因: 轉址 URL 指回原站、相對網址解析錯誤、代理規則重複命中。
  • 解法: 以絕對 URL、對遠端網域白名單；在 Handler 檢測 Referer/Host 避免再次攔截；加入 max-redirect 防護。
  • 預防: 單元測試各種路徑、啟用日誌檢查 Location 與 Host。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q5, C-Q2

D-Q3: 圖片無法顯示或載入很慢的原因？

• A簡: 遠端服務延遲、DNS/網路問題、快取未命中或熱點檔案
• A詳:
  • 症狀: 圖片長時間顯示佔位、部份地區失敗。
  • 原因: 外部圖床延遲高、跨區路由差、DNS 汙染、首訪未快取、熱點導致配額限流。
  • 解法: 檢查外部狀態頁、切換節點或暫時回本地；縮圖與壓縮；設定合理 Cache-Control；考慮就近 CDN。
  • 預防: 監控地理延遲、預熱快取、分流策略與告警。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q7, C-Q7

D-Q4: API 金鑰或權杖失效如何處理？

• A簡: 更新憑證與權杖，旋轉機制與密鑰管控，快速回退
• A詳:
  • 症狀: API 返回 401/403、權杖過期提示。
  • 原因: 憑證撤銷、權杖過期或環境變更。
  • 解法: 重新授權 OAuth；更新 Key/Secret；使用安全儲存（KeyVault）與滾動更新；在失效時自動降級回本地。
  • 預防: 權杖有效期監控與預先旋轉、最小權限與審計。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q11, C-Q3

D-Q5: 映射表錯亂或重複如何修復？

• A簡: 以唯一鍵與雜湊校驗，重建索引並清理重複條目
• A詳:
  • 症狀: 同一檔對應多個 URL、上傳重覆或找不到映射。
  • 原因: 缺乏唯一約束、併發寫入、異常中止。
  • 解法: 加唯一索引；以檔案雜湊重建映射；對重複條目保留最新有效；跑校驗作業修復缺失。
  • 預防: 交易寫入、冪等等級鎖、寫前檢查映射存在。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q9, C-Q4

D-Q6: 站點負載上升與 CPU 飆高怎麼辦？

• A簡: 背景化上傳、節流與快取優化，必要時關閉外移功能
• A詳:
  • 症狀: 高 CPU、I/O 等待、首訪延遲增長。
  • 原因: 同步上傳耗時、併發過高、快取未命中、熱點資源。
  • 解法: 背景佇列上傳，前端先回本地；加入節流與併發限制；預熱或長 TTL 快取；必要時 Feature Flag 關閉。
  • 預防: 容量規劃、負載測試、熔斷降級與監控告警。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q7, B-Q12, B-Q13

D-Q7: 無法關閉功能或設定未生效？

• A簡: 確認設定來源與快取，支援熱更新並加開關優先判斷
• A詳:
  • 症狀: 切換 Off 後仍轉址或持續上傳。
  • 原因: 設定未讀取、快取未失效、部署不同步。
  • 解法: 將開關置於流程最前；使用可監看的設定來源；清理應用快取；檢查多實例設定一致。
  • 預防: 加入狀態輸出端點、設定版本號、開關切換審計。
• 難度: 初級
• 學習階段: 基礎
• 關聯概念: B-Q13, C-Q5

D-Q8: RTSP 影片轉址失敗如何處理？

• A簡: 檢查協定支援、端口與媒體伺服器狀態，必要時臨時回本地
• A詳:
  • 症狀: 影片無法播放或播放器報連線失敗。
  • 原因: 客戶端不支援 RTSP、伺服器端口封鎖、URL 組裝錯誤。
  • 解法: 優先採用普遍支援的 HTTP/HLS；確認 RTSP 服務可達與權限；校正 URL 與權杖；暫時回本地或替代平台。
  • 預防: 事前相容性測試、提供多種播放方案、監控播放失敗率。
• 難度: 高級
• 學習階段: 進階
• 關聯概念: B-Q10, C-Q8

D-Q9: ZIP 虛擬資料夾瀏覽出錯怎麼辦？

• A簡: 檢查路徑映射與檔名編碼，改為串流並處理大檔分段
• A詳:
  • 症狀: 列目錄或下載個別檔案時錯誤或 404。
  • 原因: 虛擬路徑對應錯、大小寫與編碼差異、ZIP 損毀。
  • 解法: 校正路徑規則與大小寫；對非 ASCII 名稱統一 UTF-8；驗證 ZIP 完整性；大檔分段串流傳送。
  • 預防: 加入自動測試樣本、檔案命名規範、快取索引。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: C-Q9, B-Q9

D-Q10: 備份還原後代理失效如何修復？

• A簡: 還原映射與憑證，重新校驗遠端資源並允許回退本地
• A詳:
  • 症狀: 轉址失敗、找不到遠端 URL、401/404。
  • 原因: 映射資料遺失、環境變更導致憑證不符。
  • 解法: 還原映射資料庫與密鑰；掃描本地檔與雜湊重建映射；必要時重上傳；在期間改為本地直出。
  • 預防: 定期快照映射與憑證、演練還原流程、基礎設施即程式碼化。
• 難度: 中級
• 學習階段: 核心
• 關聯概念: B-Q8, B-Q11, C-Q4

學習路徑索引

• 初學者：建議先學習哪 15 題
  • A-Q1: 什麼是 FlickrProxy？
  • A-Q2: 為何小型網站常遇到頻寬瓶頸？
  • A-Q3: 什麼是客戶端外掛（如 WLW Flickr 插件）方案？
  • A-Q4: 什麼是伺服端透明代理的解法？
  • A-Q5: FlickrProxy 與 WLW 外掛的差異是什麼？
  • A-Q7: 什麼是 ASP.NET 的 HttpHandler？
  • A-Q8: 什麼是 Run Time 動態檢查與轉向？
  • A-Q9: 什麼是 POC（Proof of Concept）？
  • A-Q11: 何謂透明代理（Transparent Proxy）？
  • A-Q12: FlickrProxy 的核心價值是什麼？
  • B-Q4: ASP.NET 如何攔截圖檔請求？
  • B-Q5: 重新導向至 Flickr 圖片的原理是什麼？
  • B-Q1: FlickrProxy 的整體運作流程如何？
  • C-Q2: 如何設定 web.config 攔截圖片請求？
  • C-Q1: 如何在 ASP.NET 建立基本的 FlickrProxy HttpHandler？
• 中級者：建議學習哪 20 題
  • A-Q6: 為什麼選擇伺服端方案而非客戶端外掛？
  • A-Q10: 什麼是 Provider 架構？
  • A-Q14: 何謂自動上傳與重新導向？
  • A-Q15: 效能與彈性的取捨為何？
  • B-Q2: 伺服端如何判斷圖片是否需要上傳？
  • B-Q3: 自動上傳至 Flickr 的機制是什麼？
  • B-Q6: Provider 模式的技術設計如何？
  • B-Q7: FlickrProxy 如何處理快取與效能？
  • B-Q8: 如何保持本機檔案與遠端的一致性與備份？
  • B-Q9: 如何記錄本地檔與遠端 URL 的映射？
  • B-Q11: 安全與權限有哪些考量？
  • B-Q13: 如何做到隨時關閉此功能？
  • B-Q14: POC 如何驗證技巧可行？
  • C-Q3: 如何整合 Flickr API 進行上傳？
  • C-Q4: 如何設計映射儲存（SQLite/JSON）？
  • C-Q5: 如何加上功能開關（Feature Toggle）？
  • C-Q6: 如何加入白名單/黑名單規則？
  • C-Q7: 如何實作快取與 ETag/Last-Modified？
  • D-Q1: 遇到上傳 Flickr 失敗怎麼辦？
  • D-Q2: 發生重新導向循環該怎麼處理？
• 高級者：建議關注哪 15 題
  • B-Q10: 如何支援其他媒體如 YouTube 或雲端儲存？
  • B-Q12: 失敗重試與容錯機制如何設計？
  • B-Q15: 透明代理與反向代理有何差異？
  • C-Q8: 如何擴充支援 YouTube 的 Provider？
  • C-Q9: 如何將 ZIP 虛擬化為資料夾並改存雲端？
  • C-Q10: 如何監控與記錄代理行為？
  • D-Q3: 圖片無法顯示或載入很慢的原因？
  • D-Q4: API 金鑰或權杖失效如何處理？
  • D-Q5: 映射表錯亂或重複如何修復？
  • D-Q6: 站點負載上升與 CPU 飆高怎麼辦？
  • D-Q7: 無法關閉功能或設定未生效？
  • D-Q8: RTSP 影片轉址失敗如何處理？
  • D-Q9: ZIP 虛擬資料夾瀏覽出錯怎麼辦？
  • D-Q10: 備份還原後代理失效如何修復？
  • A-Q13: FlickrProxy 可支援哪些媒體？