POST 信息在 .htaccess 重定向中丢失
所以，我有一个完全可以工作的 CRUD。问题是，由于我的文件结构，我的 URL 看起来像 https://localhost/myapp/resources/views/add-product.php ，但这看起来太丑陋了，所以经过研究和这里的另一篇文章，我能够使用 .htaccess 文件使链接看起来像 https://localhost/myapp/add-product （删除 .php 扩展名和目录），我也用它来强制执行HTTPS。现在，大多数视图都工作正常，但我的批量删除视图使用索引上表单中的 POST 信息。现在重定向工作后重构代码后，批量删除视图收到一个空数组。如果我删除重定向并使用“丑陋的 URL”，它就可以正常工作。我的 .htaccess 文件如下所示：
Options +FollowSymLinks +MultiViews
RewriteEngine On
RewriteBase /myapp/
RewriteRule ^resources/views/(.+)\.php$ $1 [L,NC,R=301]
RewriteCond %{DOCUMENT_ROOT}/myapp/resources/views/$1.php -f
RewriteRule ^(.+?)/?$ resources/views/$1.php [END]
RewriteCond %{HTTPS} off
RewriteRule .* https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
我实际上没有编写任何内容，它是已回答的问题和研究之间的网格。我确实尝试根据这篇文章将 L 标志更改为 P：是否可以重定向发布数据？，但这给了我以下错误：
Internal Server Error
The server encountered an internal error or misconfiguration and was unable to complete your request.
Please contact the server administrator at [email protected] to inform them of the time this error occurred, and the actions you performed just before this error.
More information about this error may be available in the server error log.
Apache/2.4.52 (Win64) OpenSSL/1.1.1m PHP/8.1.2 Server at localhost Port 443
So, I have a fully working CRUD. The problem is, because of my file structure, my URLs were looking something like https://localhost/myapp/resources/views/add-product.php but that looked too ugly, so after research and another post here, I was able to use a .htaccess file to make the links look like https://localhost/myapp/add-product (removing .php extension and the directories), and I'm also using it to enforce HTTPS. Now, most of the views are working fine, but my Mass Delete view uses POST information from a form on my index. After restructuring the code now that the redirect works, the Mass Delete view is receiving an empty array. If I remove the redirect and use the "ugly URLs" it works fine. Here's how my .htaccess file is looking like:
Options +FollowSymLinks +MultiViews
RewriteEngine On
RewriteBase /myapp/
RewriteRule ^resources/views/(.+)\.php$ $1 [L,NC,R=301]
RewriteCond %{DOCUMENT_ROOT}/myapp/resources/views/$1.php -f
RewriteRule ^(.+?)/?$ resources/views/$1.php [END]
RewriteCond %{HTTPS} off
RewriteRule .* https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
I didn't actually write any of it, it's a mesh between answered questions and research. I did try to change the L flag to a P according to this post: Is it possible to redirect post data?, but that gave me the following error:
Internal Server Error
The server encountered an internal error or misconfiguration and was unable to complete your request.
Please contact the server administrator at [email protected] to inform them of the time this error occurred, and the actions you performed just before this error.
More information about this error may be available in the server error log.
Apache/2.4.52 (Win64) OpenSSL/1.1.1m PHP/8.1.2 Server at localhost Port 443
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
您一开始就不应该重定向表单提交。理想情况下，您应该直接链接到表单
action中的“漂亮”URL。如果您无法更改 HTML 中的action表单，请在.htaccess重定向中包含一个例外，以排除此特定 URL 被重定向。重定向表单提交并不能真正帮助任何人。用户和搜索引擎仍然可以看到“丑陋”的 URL（它位于 HTML 源代码中），并且您将击中服务器的表单提交量加倍（并使用户的带宽加倍）。
像这样的“重定向”仅适用于搜索引擎已经对“丑陋”的 URL 建立索引和/或由您无法控制的外部第三方链接到的情况。这是为了保护 SEO，就像更改任何 URL 结构一样。所有内部“丑陋”URL 都应该已转换为“漂亮”版本。这样，“丑陋”的 URL 就永远不会暴露给用户或搜索引擎。
因此，首先不需要使用 307（临时）或 308（永久）状态代码来让浏览器在重定向中保留请求方法。对于像这样的重定向，通常会看到 POST 请求的异常（因为不应重定向表单提交）。或者仅针对 GET 请求。例如：
将此重定向更改为 307/8 是一种解决方法，而不是解决方案。如果此重定向是为了 SEO（因为它应该如此），那么这应该是 308（永久），而不是 307（临时）。
旁白：
您的 HTTP 到 HTTPS 重定向位置错误。这需要作为第一个规则，或者确保您在当前的第一个规则中重定向到 HTTPS，并在重写之前将其作为第二个规则（以确保您永远不会获得双重重定向） 。
通过将此规则放在最后，任何对
/resources/views/.php （或/）的 HTTP 请求都不会升级到 HTTPS。You shouldn't be redirecting the form submission in the first place. Ideally, you should be linking directly to the "pretty" URL in your form
action. If you are unable to change the formactionin the HTML then include an exception in your.htaccessredirect to exclude this particular URL from being redirected.Redirecting the form submission is not really helping anyone here. Users and search engines can still see the "ugly" URL (it's in the HTML source) and you are doubling the form submission that hits your server (and doubling the user's bandwidth).
"Redirects" like this are only for when search engines have already indexed the "ugly" URL and/or is linked to by external third parties that you have no control over. This is in order to preserve SEO, just like when you change any URL structure. All internal "ugly" URLs should have already been converted to the "pretty" version. The "ugly" URLs are then never exposed to users or search engines.
So, using a 307 (temporary) or 308 (permanent) status code to get the browser to preserve the request method across the redirect should not be necessary in the first place. For redirects like this it is common to see an exception for POST requests (because the form submission shouldn't be redirected). Or only target GET requests. For example:
Changing this redirect to a 307/8 is a workaround, not a solution. And if this redirect is for SEO (as it only should be) then this should be a 308 (permanent), not a 307 (temporary).
Aside:
Your HTTP to HTTPS redirect is in the wrong place. This needs to go as the first rule, or make sure you are redirecting to HTTPS in the current first rule and include this as the second rule, before the rewrite (to ensure you never get a double redirect).
By placing this rule last then any HTTP requests to
/resources/views/<something>.php(or/<something>) will not be upgraded to HTTPS.