HTTP

＃從Arduino通過HTTP讀取數值 在本教程中，我想擴展Arduino Web Server教程以讀取由傳感器測量的數值，這樣我們只需打開瀏覽器上的一個頁面就可以看到數據。 例如，我們將使用DHT11傳感器測量溫度，並使用接近傳感器測量對象距離。 我們通過訪問/on URL點亮Arduino上的內置LED，並通過打開/off URL關閉它。其他任何操作都不起作用。 這是來自其他教程的代碼： #include <SPI.h> #include <WiFiNINA.h> WiFiServer server(80); void setup() { char ssid[] = SECRET\_SSID; char pass[] = SECRET\_PASS; Serial.begin(9600); while (!Serial); int status = WL\_IDLE\_STATUS; while (status != WL\_CONNECTED) { Serial.print("Connecting to "); Serial.println(ssid); status = WiFi.begin(ssid, pass); delay(5000); } Serial.print("IP address: "); Serial.println(WiFi.localIP()); server.begin(); } void loop() { WiFiClient client = server.available(); if (client) { String line = ""; while (client.connected()) { if (client....

一個方便的參考，列出所有請求物件屬性以及如何使用它們 請求參數 我提到過請求物件保存了所有的HTTP請求信息。 這些是你可能會用到的主要屬性： 屬性 描述 .app 保存了對Express應用程式物件的引用 .baseUrl 應用程式回應的基本路徑 .body 包含請求主體中提交的資料（必須在可以訪問它之前對其進行解析和填充） .cookies 包含請求中傳送的 cookie（需要 cookie-parser 的中介軟體） .hostname 主機名稱，根據 Host HTTP 標頭 的值 .ip 客戶端的 IP 位址 .method 使用的 HTTP 方法 .params 命名路由參數 .path URL 路徑 .protocol 請求協議 .query 包含請求中使用的所有查詢字串的物件 .secure 如果請求是安全的（使用 HTTPS）則為 true .signedCookies 包含請求中傳送的簽名 cookie（需要 cookie-parser 的中介軟體） .xhr 如果請求是 XMLHttpRequest 則為 true 如何使用 Express 擷取 GET 查詢字串參數 查詢字串是 URL 路徑後面的部分，以問號 ? 開頭。 例如： ?name=flavio 可以使用 & 添加多個查詢參數： ?name=flavio&age=35 如何在 Express 中獲取這些查詢字串的值？...

探索HTTP和HTTPS之間的主要差異，了解為什麼HTTPS對於一切都更快更好。 HTTP（超文本傳輸協議）是我們所知的網絡的協議基礎。 它位於TCP之上，TCP位於IP之上。 網頁可以使用HTTP或HTTPS（超文本傳輸協議安全版）。 它們有什麼不同？為什麼現在Chrome將HTTP標記為不安全呢？ 安全性 當您從服務器請求一個HTTP頁面時，數據會通過許多不同的網絡，每個網絡都由一個單獨的公司或實體控制。 從WiFi路由器開始，可能是咖啡店擁有的，也可能是城市公共網絡基礎設施擁有的，網絡中的每個節點都可以看到請求和響應，並以任何方式修改它。 它們可能會注入廣告，可能會注入惡意軟件，可能會記錄您輸入的任何憑據。中間的服務器可以充當中間人，發送被破壞的信息。 這也適用於任何未安全的Internet協議。 HTTPS流量是端到端加密的，這意味著在您和網絡另一端的服務器之間交換的信息中間沒有任何人可以閱讀。 端口 默認情況下，HTTP使用端口80提供服務，而HTTPS使用端口443提供服務。這些是默認端口，但Web服務器可以選擇在不同的隨機端口上提供內容，此時您需要在地址欄中指定： http://flaviocopes.com http://flaviocopes.com:80/javascript https://flaviocopes.com:8081/javascript HTTPS速度慢嗎？ 不是！相反地。 有一個關於頁面速度的神話。人們認為為了HTTPS所需要的TLS握手會使頁面速度變慢，但實際上，HTTPS頁面可以比HTTP頁面加載得更快。 為什麼？因為有了HTTP/2，HTTP協議的最新版本。HTTP/2可以並行提供請求，並要求建立安全連接，因此，如果您的服務器使用支持HTTP/2的現代Web服務器，那麼使用HTTPS時，您的網頁將會有顯著的速度提升。 HTTP/2引入了更好的並行處理、多路複用和壓縮，這是HTTP的一個很好的更新。 請參閱以下網頁的示例：<https://www.httpvshttps.com/>和<https://www.troyhunt.com/i-wanna-go-fast-https-massive-speed-advantage/> HTTPS是否會影響SEO？ 是的。 特別是，Google表示，HTTPS在SEO方面會給您帶來優勢。 此外，Google將會在其Chrome瀏覽器中正式將HTTP網站標記為不安全，這清楚地表明，如果您關心Google的需求並且想利用這一點，您應該盡快切換到HTTPS。最好的時間應該是3年前，下一個最好的時間就是今天。 實施HTTPS是否困難？ 一點也不。由於Let’s Encrypt提供免費的SSL證書，對HTTPS的推動產生了巨大的影響，現在每個體面的託管提供商都免費為所有帳戶實施它。多虧了這一點，在2018年HTTPS連接比HTTP連接更多。 在過去，對於一個普通網站來說，獲得SSL證書是一個高級選項，只有少數人願意為之支付費用，因為該網站不會賺錢或者不處理用戶數據。 如今已經沒有任何藉口了。

當資源需要傳輸時，快取是一種可以加快網絡連接速度的技術，因為傳輸的東西越少，效果就越好。 許多資源可能非常龐大，從時間和實際成本（例如在移動設備上）的角度來看都非常昂貴。 HTTP 提供了不同的快取策略，並由瀏覽器使用。 無快取 Expires 首部 條件式 GET 使用 If-Modified-Since 和 Last-Modified 使用 If-None-Match 和 ETag 無快取 首先，Cache-Control 首部可以告訴瀏覽器在檢查 ETag 值（稍後詳述）之前，永遠不要使用快取的資源，如下所示： Cache-Control: no-cache 更嚴格的 no-store 選項告訴瀏覽器（以及所有中介網路設備）不要將資源存儲在其快取中： Cache-Control: no-store 如果 Cache-Control 中含有 max-age 值，則此值用於確定該資源作為快取的有效時間（單位為秒）： Cache-Control: max-age=3600 Expires 首部 當發送 HTTP 請求時，瀏覽器會檢查其快取中是否有該頁面的副本，基於所請求的 URL。 如果有，則檢查該頁面的新鮮度。 如果HTTP 回應 Expires 首部（/http-response-headers/#expires）值小於當前日期和時間，則該頁面被認為是新鮮的。 Expires 首部的格式如下： Expires: Sat, 01 Dec 2018 16:00:00 GMT 條件式 GET 有不同的條件式 GET 方法。它們都基於使用 If-* 請求頭： 使用 If-Modified-Since 和 Last-Modified 使用 If-None-Match 和 ETag 使用 If-Modified-Since 和 Last-Modified 瀏覽器可以發送帶有 If-Modified-Since 首部的請求到服務器，該頭部基於當前快取頁面中獲取的 Last-Modified 首部值。...

每個 HTTP 回應都有一組標頭。這篇文章旨在列出所有這些標頭，並對它們進行描述。 每個 HTTP 回應都可以有一組標頭。 這篇文章旨在列出所有這些標頭，並對它們進行描述。 標準標頭 Accept-Patch Accept-Ranges Age Allow Alt-Svc Cache-Control Connection Content-Disposition Content-Encoding Content-Language Content-Length Content-Location Content-Range Content-Type Date Delta-Base ETag Expires IM Last-Modified Link Location Pragma Proxy-Authenticate Public-Key-Pins Retry-After Server Set-Cookie Strict-Transport-Security Trailer Transfer-Encoding Tk Upgrade Vary Via Warning WWW-Authenticate CORS 標頭 非標準標頭 Content-Security-Policy Refresh X-Powered-By X-Request-ID X-UA-Compatible X-XSS-Protection 標準標頭 Accept-Patch Accept-Patch: text/example;charset=utf-8 指定此服務器支援的修補文件格式。 Accept-Ranges Accept-Ranges: bytes 指示這個伺服器通過字節給服務支援哪些部分內容範圍類型。 Age Age: 12 對象在代理快取中的存放時間，以秒為單位。 Allow Allow: GET, HEAD...

每個 HTTP 響應都附帶一個狀態碼，以明確的數字信息表明請求的處理方式。 HTTP 狀態碼是從服務器發送給客戶端的 HTTP 響應的首行。 如果您想知道服務器為什麼發送了特定的狀態碼以及它的含義，或者如果您正在構建服務器並且正在尋找要返回的完美的狀態碼，這個列表將非常有用。 狀態碼由 3 位數字和一個簡短的描述組成。 數字的第一位確定了響應組。 共有五個組： 1xx：信息性響應 - 表示請求已接收且已被理解 2xx：成功的響應 - 表示客戶端發出的請求已被接收、理解和接受 3xx：重定向 - 表示客戶端必須採取其他操作才能完成請求 4xx：客戶端錯誤 - 表示發生了客戶端引起的錯誤 5xx：服務器錯誤 - 表示發生了服務器上的錯誤 在本文的其餘部分中，我列出了所有有用的狀態碼。 （我刪除了一些特定於技術的狀態碼，例如 WebDAV 和很少使用的狀態碼） 信息性響應 狀態碼 描述 100 Continue 服務器已收到請求標頭，客戶端應繼續發送請求正文（例如，POST 請求）。 在請求被拒絕適用於不適當的標頭之後，將大的請求正文發送到服務器可能是低效的。 要求服務器檢查請求的標頭，客戶端必須在初始請求中作為標頭發送 Expect: 100-continue，並在接收到 100 Continue 狀態碼的響應後再發送正文。 如果客戶端收到 403（Forbidden）或 405（Method Not Allowed）等錯誤碼，那麼它就不應該發送請求的正文。 回應 417 Expectation Failed 表示應該重複請求，而不使用 Expect 標頭，因為它表示服務器不支持期望（對於 HTTP/1.0 服務器來說就是這種情況）。 101 Switching Protocols 客戶端要求服務器切換協議，服務器已同意切換。參見 RFC 7231 ＃6.2.2 成功的響應 狀態碼 描述 200 OK 標準的成功 HTTP 請求響應。 201 Created 通常是對 POST 請求的回應。請求已完成，並創建了新的資源。 202 Accepted 請求已被接受處理。對實際處理以及結果沒有具體要求，可能發生在另一個服務器上或批量處理。 203 Non-Authoritative Information 原始服務器返回了 200，並且位於客戶端和服務器之間的轉換代理更改了有效負載。 204 No Content 服務器成功處理了請求，但沒有返回任何內容。 205 Reset Content 服務器成功處理了請求，但沒有返回任何內容。類似於 204 響應，但服務器要求客戶端重置文檔視圖（例如用於清除表單） 206 Partial Content 根據客戶端發送的 Range 請求，服務器發送部分內容的響應。參見 RFC 7233 ＃4....

WebSockets是Web應用程序中HTTP通信的替代方案。它們提供了一個客戶端和服務器之間長期存在的、雙向的通信通道。讓我們來了解如何使用它們來進行網絡交互。 WebSockets是Web應用程序中HTTP通信的替代方案。 它們提供了一個客戶端和服務器之間長期存在的、雙向的通信通道。 一旦建立，該通道保持打開，提供了非常快速的連接和低延遲和開銷。 WebSockets的瀏覽器支持 WebSockets在所有現代瀏覽器中都得到支持。 WebSockets和HTTP的區別 HTTP是一種非常不同的協議，也是一種不同的通信方式。 HTTP是一種請求/響應協議：當客戶端請求時，服務器返回一些數據。 而WebSockets這樣： 服務器可以在客戶端不明確請求的情況下向客戶端發送消息 客戶端和服務器可以同時交談 傳送消息時只需交換非常少的數據開銷。這意味着低延遲通信。 WebSockets非常適合實時和長期存在的通信。 HTTP非常適合偶爾的數據交換和客戶端發起的交互。 HTTP實現起來要簡單得多，而WebSockets則需要更多的開銷。 安全的WebSockets 請始終使用安全、加密的WebSockets協議，即wss://。 ws://是不安全的WebSockets版本（WebSockets的http://），出於明顯原因應該避免使用。 建立新的WebSockets連接 const url = 'wss://myserver.com/something' const connection = new WebSocket(url) connection是一個WebSocket對象。 在連接成功建立時，將觸發open事件。 通過將回調函數賦值給connection對象的onopen屬性來監聽它： connection.onopen = () => { //... } 如果出現任何錯誤，將觸發onerror回調函數： connection.onerror = (error) => { console.log(`WebSocket error: ${error}`) } 使用WebSockets將數據發送到服務器 一旦連接打開，您可以向服務器發送數據。 您可以在onopen回調函數內部輕松地這樣做： connection.onopen = () => { connection.send('hey') } 使用WebSockets從服務器接收數據 通過在onmessage上設置回調函數來監聽message事件，當接收到該事件時將調用此函數： connection.onmessage = (e) => { console.log(e.data) } 在Node.js中實現服務器 ws是Node.js的一個流行的WebSockets庫。...

XMLHttpRequest（XHR）的引入是Web平台的重大胜利。让我们看看它是如何工作的。 介紹 一個XHR請求的例子 附加的open()參數 onreadystatechange 中止XHR請求 與jQuery的比較 與Fetch的比較 跨網域請求 使用XHR上傳文件 介紹 在2000年代中期，網絡瀏覽器中引入XMLHttpRequest（XHR）是Web平台的重大突破。讓我們看看它是如何工作的。 許多現在看起來很正常的東西，在當時看起來就像來自未來。例如，我談論的GMail或Google Maps在很大程度上都依賴於XHR。 XHR是在九十年代由Microsoft發明的，由於所有瀏覽器在2002年至2006年期間都實現了它，它成為事實上的標准。W3C於2006年將XMLHttpRequest標准化。 就像在Web平台上有時會發生的情況一樣，最初有一些不一致之處，這使得在不同的瀏覽器中使用XHR變得非常不同。 像jQuery這樣的庫通過提供一個易於使用的抽象層，受到開發人員的歡迎，這反過來又幫助傳播了這項技術。 一個XHR請求的例子 以下代碼創建一個XMLHttpRequest（XHR）請求對象，並附加一個在onreadystatechange事件上響應的回調函數。 xhr連接的設置為向https://yoursite.com發送GET請求，並使用send()方法開始： const xhr = new XMLHttpRequest() xhr.onreadystatechange = () => { if (xhr.readyState === 4) { xhr.status === 200 ? console.log(xhr.responseText) : console.error('error') } } xhr.open('GET', 'https://yoursite.com') xhr.send() 附加的open()參數 在上面的例子中，我們只傳遞了方法和URL給請求。 我們還可以指定其他HTTP方法-（get，post，head，put，delete，options）。 其他參數讓您可以指定一個標誌，如果將其設置為false，則可以使請求同步進行，並為HTTP驗證指定一組憑據： open(method, url, asynchronous, username, password) onreadystatechange onreadystatechange在XHR請求期間多次被調用。我們明確忽略除readyState === 4以外的所有狀態，這意味著請求已完成。 狀態有： 1（OPENED）：請求開始 2（HEADERS_RECEIVED）：已接收到HTTP標頭 3（LOADING）：響應開始下載 4（DONE）：響應已下載 中止XHR請求 可以通過在xhr對象上調用abort()方法來中止XHR請求。 與jQuery的比較 在使用jQuery時，這些代碼可以轉寫為： $.get('https://yoursite.com', data => { console....

了解如何使用 Node 通過 HTTP 請求體提取發送的 JSON 數據。 這是如何提取請求體中作為 JSON 發送的數據。 如果你使用的是 Express，那就非常簡單：使用 body-parser Node 模塊。 例如，要獲取此請求的請求體： const axios = require('axios') axios.post('/todos', { todo: '購買牛奶', }) 這是對應的服務器端代碼： const bodyParser = require('body-parser') app.use( bodyParser.urlencoded({ extended: true, }) ) app.use(bodyParser.json()) app.post('/endpoint', (req, res) => { console.log(req.body.todo) }) 如果你沒有使用 Express，而是想在原生的 Node 中實現這個功能，當然需要更多的工作，因為 Express 為你抽象了很多內容。 關鍵的是，當你使用 http.createServer() 初始化 HTTP 服務器時，回調函數被調用時，服務器已經獲取了所有的 HTTP 標頭，但是沒有請求體。 在連接的回調中，傳遞的 request 對象是一個流。 因此，我們需要監聽請求體內容被處理的事件，並且它以塊的形式進行處理。 我們首先通過監聽流的 data 事件來獲取數據，在數據結束時，流的 end 事件被調用一次： const server = http.createServer((req, res) => { // 我們可以訪問 HTTP 標頭 req....

curl是一個強大的工具，可以讓你從命令行創建網絡請求。 curl是一個命令行工具，用於在網絡上傳輸數據。 它支持許多協議，包括HTTP、HTTPS、FTP、FTPS、SFTP、IMAP、SMTP、POP3等。 在調試網絡請求方面，curl是最好的工具之一。 這是一個工具，一旦你知道如何使用它，你就會再次使用。它是程序員最好的朋友。 它是通用的，可以在Linux、Mac、Windows上運行。請參考官方安裝指南在你的系統上安裝它。 有趣的事實：curl的作者和維護人員是瑞典人，因他的工作（curl和libcurl）對計算世界的貢獻而被瑞典國王授予獎項。 讓我們深入介紹一些與HTTP請求一起工作時，你最有可能執行的命令和操作。 這些示例涉及與HTTP一起工作，這是最常用的協議。 執行HTTP GET請求 獲取HTTP響應頭 僅獲取HTTP響應頭 執行HTTP POST請求 執行HTTP POST請求並發送JSON 執行HTTP PUT請求 跟隨重定向 將響應保存到文件中 使用HTTP驗證 設置不同的User Agent 檢查請求和響應的所有詳細信息 將任意瀏覽器網絡請求複製為curl命令 執行HTTP GET請求 當你執行一個請求時，curl將返回響應的主體： curl https://flaviocopes.com/ 獲取HTTP響應頭 默認情況下，curl在輸出中隱藏響應頭。要顯示它們，使用i選項： curl -i https://flaviocopes.com/ 僅獲取HTTP響應頭 使用I選項，你可以僅獲取響應頭，而不是響應體： curl -I https://flaviocopes.com/ 執行HTTP POST請求 X選項允許你更改HTTP方法。默認情況下，使用GET，等同於： curl -X GET https://flaviocopes.com/ 使用-X POST將執行POST請求。 你可以執行URL編碼的POST請求： curl -d "option=value&something=anothervalue" -X POST https://flaviocopes.com/ 在這種情況下，發送application/x-www-form-urlencoded的Content-Type。 執行HTTP POST請求並發送JSON 與上面的示例不同，你可能希望發送JSON。 在這種情況下，你需要明確設置Content-Type頭，使用H選項： curl -d '{"option": "value", "something": "anothervalue"}' -H "Content-Type: application/json" -X POST https://flaviocopes....