当机器人使用HEAD攻击我的ASP.NET MVC站点时,我想正确支持HTTP HEAD请求.我注意到,对网站的所有HTTP HEAD请求都返回404,特别是来自http://downforeveryoneorjustme.com.哪个真烦人.希望他们像其他所有好机器人一样切换到GET.
如果我只是[AcceptVerbs(HttpVerbs.Get)]改为[AcceptVerbs(HttpVerbs.Get | HttpVerbs.Head)]将MVC知道放弃请求的正文？
你做了什么来支持HTTP HEAD请求？(代码示例会很棒!)
我正在向通过CloudFront提供的文件发送ajax HEAD请求.在S3中为此文件设置的max-age是1800.始终错过CloudFront中的缓存.
这是预期的行为吗？或者是否需要配置任何内容以便HEAD请求在max-age中指定的时间之前到达cloudfront？
编辑
两个连续的头部请求/响应如下:
要求1
Request URL:https://360-dev.web-dev.mydomain.com/resources/data/master.json
Request Method:HEAD
Status Code:304 Not Modified
Remote Address:52.84.105.65:443
Response Headers
view source
Cache-Control:max-age=1800, private
Connection:keep-alive
Date:Tue, 27 Sep 2016 10:20:56 GMT
ETag:"213cd6a833efde3409a8dc3808e01c46"
Last-Modified:Thu, 22 Sep 2016 11:35:17 GMT
Server:AmazonS3
Via:1.1 f2eee4ce6eb32d1b7578af7dc2c917de.cloudfront.net (CloudFront)
X-Amz-Cf-Id:QgmjSCu2uIam9Jmo63a8g-qytd6OsyalTEpNUGOaMp0EtJkheENkIA==
x-amz-storage-class:REDUCED_REDUNDANCY
X-Cache:Miss from cloudfront
Request Headers
view source
Accept:*/*
Accept-Encoding:gzip, deflate, sdch, br
Accept-Language:en-US,en;q=0.8
Cache-Control:max-age=0
Connection:keep-alive
Content-Type:application/x-www-form-urlencoded
Cookie:UnicaID=gU6xZpJesOr-Z6LqaYt; __utma=227427714.2013234852.1473314245.1473314245.1473314245.1; __utmz=227427714.1473314245.1.1.utmcsr=google|utmccn=(organic)|utmcmd=organic|utmctr=(not%20provided); SMIDENTITY=qDrbSpOZGmtMUtkclvRVlc+KUiEI64G3S7hLBFdqQCoWNLGHde2Ra7dVVWFmIjMXbUR5y3gyxjPBFA8Lcugrv3hY87qavk7fpL2XSLfBSDo4s2hMJeJXD69/iMJwe09pf7ZRxguLJc/o+lDEcIG/rLxtBBNbXnjavsLs5sipgR9A0Wf+XHLEUtBPztis4ydwMZbOoxb3kxmyuUceJgKsCA6un4FhMR3OZrbWyh6S9lEQ4/1KgHyf3P5CZwmit0ZUawjOnFMTyH/TWml3EB/spjeB69N64FDf4DsigqqFq/06Bp6nmXeq2dn9TWTWtJ3DNeSu62JyjE2KJ/59wkJ4NHzpPjiHRtbhh441bisCqjoHQ1KKrkKvnIlbNs7Brql04DRlEvIBuycumQD4DYbESvto3gw0rGpKDiD13k6AUJ/pyI7974aQcR8i9eCXWBPD5Jnx+J+DWGh1XWXCRZgu6jBGQ6sx/e6yfuo45eLqXpa7D+qBBFDSoBjtgog30vIyKcpHwcLa603X22K9wdspX/DO8QuV2vBMtYcaYC85Y3NC+0jznqfIUOqqvPvHk24dEnyS9iB6lyd9KqDR6HPcjwMzBtXdWnv0EZKwssrqgEAJL7eOfxptOpG3u5mf3YL8; SMSESSION=yOYBm7PNsDUiLFC/accSxCQgb8Ps8ZOJwWABqge/q3ktPHwef0AAtP31vm3mSkmB6Xny0NyevVx4NgkvoREs3K8lHNrNPabQAW6TJYQ4X3DMWK0HvrsaJYDRWA+lHqQCsZeOaYOwH6WxecH8jIcBC6MZmoG3eBuyegeFi2yJG/jqRi2FkcV4c4ffvg3FTUmF3GcMRvGI4G+YC5WubDhwKs7p1M/e3XyUCM6FwCTnSRVLhDt1q6M+4HJAw7j3B73mdt3axe9wzZ5lSsNGAzyI8v/2i9avLdEHtbIJSpgkWjEIWlNDgPj/jhtttY0zugLAttAblbPZr+w9Mvafh8fRmYHlBLr8sFjJFEk1fs8sqs9I+GRa8KFfk9UPImSu5iiIML9HH/ga/KaSvfL7BvZ/vUvqeudXIy3zR10j1uy9dLKAlduuSqoYwJrLpa5+u4hRRl8450JQLsNry9slNL4zTBYrE6aFsKKsu/+rTXq4tZ/fFWBMz28rC2JRroBhtmAbV3MMqw/WonCUpEyHxsRzDYHu+sAQhP585Pf3l2zxN63aqtzYqK5lE5pKyF8ivb1zFgdE5aZbGSYsjIw2p1l3MCfZDOkIqUiorNxVgz9vXCaafOblEARizV5nwMC/k+VqNuhBZgcTfNt3izOXfZfTxw+VG2eO97jgO/0XpDTix2Ok9VcS5r1jYJ6Afbo12fWWOk4oC835jOvtINjI8GYQmI3qS/Hy1gHIynU31o5X7cQyOOM4OC0JbnSXWwbvP+c03j8fh1jVpv03pW/0HlQvhbtWIgcB3YAUSnKChu8Ae29UhAZFPvzvg0pmM5zk31J5TLJq0ng9glu21hcD7kLU69ytzMKHwZTMIf9HdYFKJLfaLVSqo328E+yZ7kuaGvLX0Xt5qQHPaoYEbuU2HnLkh8DxIuv7hp7t8aNUaqsEVuhr1cDzV52Wzt0WMUP6KP149MmXTzn8s1FrHtzUxkGdAjj9HBF5AHpoUa79XPCpI7etRX2Beo2IZHg5BvDtYBv8ntczsQNNYyCqAUzD6ZE4u7nHssmLnDT+; CloudFront-Policy=eyJTdGF0ZW1lbnQiOlt7IlJlc291cmNlIjoiaHR0cHM6Ly8zNjAtZGV2Ki53ZWItZGV2LmJtcy5jb20vKiIsIkNvbmRpdGlvbiI6eyJEYXRlTGVzc1RoYW4iOnsiQVdTOkVwb2NoVGltZSI6MTQ3NTAwNjQ2OX19fV19; CloudFront-Signature=SvN~2tPgK~N~GzoY2pVOFZN1nic4t2Kgq3AucGD8gvuGS4iqjnlBIceFM~k5ZHZRlSbWa8V8QZzoYuMZvY2GvAjGJrDigJD93Vxq0qCm6alexx5~yxtX1FebaFAp68fgqo1tbjVYm7nCYrvGl2RebFcucbN6RC-Lo6aBvPnIgTrXqa6OrJKgxQQxii~LE7l9XnnKHWoYnrjBZEFWuqJ5fHrWK1MennKKAh67nOO9OGznX9slQRXBGCpNV4SCICzQEMaMxHBANjVE7nTfP9YussBV-AXYaQdkvdNt6LWcDotZu~wDDqlrBpNcru6EqJackyUAOvS982t4BPGAiL1jjQ__; CloudFront-Key-Pair-Id=APKAIOWOUVDQ5VOOZ5IA; Custom-Insite-Cookie=eyJMREFQR3JvdXAiOlsiIl0sInVzZXJOYW1lIjoic3VicmFtbTIiLCJpbnRlcm5ldCI6dHJ1ZSwiZW52aXJvbm1lbnQiOiIzNjAtZGV2IiwibG9naW5EYXRlIjoiMjAxNi0wOS0yN1QxMDowMTowOS4zODhaIn0%3D; rtFa=fa1/uY2RI0bciZ9ZZSoGEQfpjl1ezr5wmPN7/U+ySlNuu2iSn1blhq9qeQBW2Iq3gSllMAAlV5troHg6UfB2KKR7TkNU5Q3IS3TnYS+XJJxSaLXv5ghig7fDjU1KKCs9IbrJaCW9XIMzgtfDlxXE/EHRhD3+u5xX4KegxZwGjWMMNM0QOOZrtMvk98h08BhpKfAChj8CPmeaghOehRhgxbOlLwQ+1AHIgrZ4Y8n7sbW4zw4NnAPhTgdtfJ43midH1pfqIH5ijy5x4a+61nczQFkI9+WxMfqsBVJDDteeBLVc+NPuWw84JRlar01jB4Qpm0VFzt8sXMOApfNosrsgR1iQmlcdZqSpMcrKIEwKw11GZiyNGyVzMd3R1/vzQI9gIAAAAA==
Host:360-dev.web-dev.mydomain.com
If-Modified-Since:Thu, 22 Sep 2016 11:35:17 GMT
If-None-Match:"213cd6a833efde3409a8dc3808e01c46"
Referer:https://360-dev.web-dev.mydomain.com/home.html
User-Agent:Mozilla/5.0 (Windows NT …我们有一个ASP.Net MVC3站点只能通过HTTPS访问,方法是使用控制器上的RequireHTTPS属性.
我们收到了许多HTTP HEAD方法请求,主要来自看似Twitter的机器人.默认的ASP.Net/MVC3响应是'500内部服务器错误',正在被elmah和log4net捕获/记录(现已过滤掉!).
我可以根据这个问题编写一个特定的控制器和路由来处理这些非HTTPS请求 - 在asp.NET MVC 3中响应HEAD请求.
但是,从机器人的角度来看,最好的反应是什么呢？200显示服务器是活动的,302重定向到HTTPS网址,还是坚持500,因为网站无法通过HTTP访问？
在我们的内部angularjs项目中,其中一个服务有$http.head()我正在尝试测试的调用.
为了测试,我正在使用由提供的Fake HTTP后端angular-mocks.这是相关代码:
it('handle status code 200', inject(function ($httpBackend, ConnectionService) {
spyOn(Math, 'random').andReturn(0.1234);
httpBackend = $httpBackend;
httpBackend.expectHEAD('ping?rand=1234').respond(200);
ConnectionService.sendRequest();
httpBackend.flush();
expect(ConnectionService.stats.packetsReceived).toEqual(5);
httpBackend.verifyNoOutstandingExpectation();
httpBackend.verifyNoOutstandingRequest();
}));
将测试结果运行到以下错误中:
PhantomJS 1.9.7 (Mac OS X) connection service tests sendRequest function handle status code 200
FAILED TypeError: 'undefined' is not a function (evaluating 'httpBackend.expectHEAD('ping?rand=1234')')
at /path/to/app/app-connection-service_test.js:66
at d (/path/to/app/bower_components/angular/angular.min.js:35)
at workFn (/path/to/app/bower_components/angular-mocks/angular-mocks.js:2159)
经过一番挖掘后,我发现了相关的github问题:
据我所知,这意味着expectHEAD()在角度模拟中确实没有方法 - 它已被记录,但实际上,它还不是稳定角度释放的一部分.
什么是最好的方法？
请注意,我必须保持angular <= 1.2,因为此应用程序需要在IE8上运行(Angular 1.3正在放弃对IE8的支持).
我正在考虑的一个解决方法是替换head()为get().在这种情况下,我可以用现有 …
在我的 ASP.NET 核心控制器中，我有以下 HttpGet 函数：
[HttpGet("[action]")]
[HttpHead("[action]")]
[ResponseCache(NoStore = true)]
public async Task<IActionResult> GetProofPdf(long studentid)
{
var rawPdfData = await _studentLogic.StudentPdfAsync(User, studentid);
if (Request.Method.Equals("HEAD"))
{
Response.ContentLength = rawPdfData.Length;
return Json(data: "");
}
else
{
return File(rawPdfData, "application/pdf");
}
}
这确实工作得很好。返回的文件对象可以从浏览器保存。唯一的问题是在 IE 中嵌入 PDF。IE首先发送HEAD请求。HEAD 请求失败，因此 IE 甚至不会尝试获取 PDF。其他浏览器在 HEAD 失败时不会发送 HEAD 或使用 GET，但 IE 不会。
因为我想要支持 IE，所以我想创建一个 HEAD 操作。仅添加[HttpHead("[action]")]到该函数是行不通的，可能是因为对于 HEAD 来说，内容必须为空（“HEAD 方法与 GET 相同，只是服务器不得在响应中返回消息正文。”）。
那么如何在 ASP.NET Core 中创建 HttpHead-Verb-Function？如何返回空内容但返回正确的内容长度？
我目前正在使用GET获取有关文件的信息,如果我使用HEAD请求重写它会更快吗？原因我在第一次响应后关闭连接.
我想做一个简单的HTTP HEAD请求,没有keep-alive.
我怎么能在Android中做到这一点？
使用下面的测试类,该行///// 1 /////抛出a NoHttpResponseException(请参阅问题末尾的日志跟踪异常跟踪).执行任何其他行会///// 2-to-8 /////打印出标题.这是HttpClient 4.3.x中的一个错误还是我做错了(我用4.3.1和4.3.2测试了这个)？
import java.util.Arrays;
import org.apache.http.client.methods.*;
import org.apache.http.impl.client.*;
import org.apache.http.params.*;
public class PrintHeaders {
private static final String MONEY_SMART_URL = "https://www.moneysmart.gov.au/?";
private static final String TGA_URL = "https://www.ebs.tga.gov.au/ebs/picmi/picmirepository.nsf/PICMI?OpenForm&t=&k=P";
private static final String DEFAULT_USER_AGENT = "Mozilla/5.0 (Windows NT 6.1; WOW64; rv:26.0) Gecko/20100101 Firefox/26.0";
public static void main(String[] args) throws Exception {
printHeadersByHead_4_3(TGA_URL); ///// 1 /////
// printHeadersByHead_4_2(TGA_URL); ///// 2 /////
// printHeadersByGet_4_3(TGA_URL); ///// 3 /////
// printHeadersByGet_4_2(TGA_URL); ///// 4 /////
// …我发现有些服务器以 HTTP 405 响应请求HEAD（或另一个状态代码，包括 404，这在 IMO 中令人困惑，但这现在并不重要），即使GET请求以 HTTP 200 响应。HTTP 405定义为...
405 不允许的方法
Request-URI 标识的资源不允许使用 Request-Line 中指定的方法。响应必须包含一个允许标头，其中包含所请求资源的有效方法列表。
好吧，我查看了Allow标题，发现我可以用来GET获取资源（尽管我只想知道资源是否存在）。问题解决了。
但是，我的问题是......为什么服务器会不允许该HEAD方法？优点是什么？是否有可能的安全原因？
我有一个域名要测试。Ping 约为 20 毫秒。“HTTP HEAD”大约是 500 毫秒。
为什么他们之间有这么大的区别？这是服务器端的问题吗？是不是差别太大了？25 次。
我一直在测试我编写的一个小应用程序,它基本上会执行http HEAD请求以检查页面是否存在,重定向等等.我注意到有些页面对HEAD的响应与GET请求不同.例如:
curl -I http://www.youtube.com/bbcpersian
返回404.肯定会有.一些(相当重要的)网站甚至返回500个错误以响应HEAD - 我猜这不是故意的.
所以我的问题是:
虽然表现得像这样的页面数量很少,但每个误报最终都是人工调查的,这导致了大量的浪费.
在Rails应用程序中,我想为资源(用户提供的URL)发出HTTP HEAD请求,以确保它存在.我还想要超时,以确保在花费一段合理的时间等待之后该方法失败.实现这一目标最简单的方法是什么(如果可能,使用标准库)？
http-head ×13
http ×7
acceptverbs ×1
android ×1
angularjs ×1
asp.net-core ×1
asp.net-mvc ×1
c# ×1
http-get ×1
http-headers ×1
http-verbs ×1
httpclient ×1
httprequest ×1
https ×1
java ×1
javascript ×1
ping ×1
python ×1
request ×1
ruby ×1
scripting ×1
web-crawler ×1
webserver ×1