We have an ISAPI module and filter that inspects and modifies responses. We have this scenario where Firefox with HTTP2 enabled sends a request that fails within IIS, and a second request is immediately re-introduced into the pipeline (perhaps resent from the Firefox client). The two requests are very similar except the first one had TE: trailer header and connection:close. When looking at the Failed Request Trace, we see that the flush on the first request fails with 'the parameter is incorrect' (below). Is there a way to track down more information on why the flush failed? I tried to track it down within the managed pipeline but wasn't able to - it seems it may be occurring within native code, or maybe a communication error back to the client(?). If Firefox has HTTP2 disabled, the flush error doesn't occur. If we don't have the ISAPI module and filter, the first request succeeds.
0 ms
Verbose
GENERAL_RESPONSE_ENTITY_BUFFER
Buffer
HTTP/1.1 302 Found
Content-Length: 192
Content-Type: text/html; charset=utf-8
Location: https://SERVER-NAME/VDIR/PATH/FILE.aspx?url=https%3a%2f%2fSERVER-NAME%2fVDIR
Server: Microsoft-IIS/10.0
request-id: b8945a72-543a-4474-9837-9420b3176c5b
X-Powered-By: ASP.NET
X-X-Server: SERVER-NAME
<html><head><title>Object moved</title></head><body>
<h2>Object moved to here.</h2>
</body></html>
0 ms
Informational
GENERAL_FLUSH_RESPONSE_END
BytesSent
0
ErrorCode
The parameter is incorrect.
(0x80070057)
0 ms
GENERAL_REQUEST_END
BytesSent
0
BytesReceived
733
HttpStatus
302
HttpSubStatus
0 ```
Related
I have this nagging error message on accessing an endpoint on azure portal.
Any one could help?
HTTP/1.1 401 Unauthorized
cache-control: none
content-length: 0
content-security-policy: script-src 'self'
date: Tue, 23 Nov 2021 16:47:15 GMT
expect-ct: max-age=604800,enforce
ocp-apim-apiid: cash-code
ocp-apim-operationid: generate-cashcode
ocp-apim-subscriptionid: master
For me this was simply a case of using the wrong "secret" i.e. I accidentally used the SecretID instead of the value of the secret.
That was allowing me to get a code without an error message, but the code was not actually valid even though it looked like a proper code, and all I got back was the infamous 401 without a clue as to why it was happening.
I have defined a rewrite rule on my Azure application gateway that is rewriting a response header (Server=Unknown). I see that the rule is correctly executed on a GET, OPTIONS, DELETE method (returning either HTTP 200 or 405), however the rule does not seem to be fired on a TRACE method.
I wanted to address a finding from penetration tests that state that the server discloses technical information allowing an attacker to be informed of the reverse proxy installed.
Below is a screenshot of the HTTP DELETE method:
HTTP/1.1 405
Date: Mon, 02 Nov 2020 14:47:18 GMT
Content-Type: text/plain
Content-Length: 0
Connection: keep-alive
X-FRAME-OPTIONS: SAMEORIGIN
X-XSS-Protection: 1; mode=block
X-Content-Type-Options: nosniff
Cache-Control: no-cache,no-store,must-revalidate
Pragma: no-cache
Allow: GET
Server: Unknown
And below the same call using TRACE:
HTTP/1.1 405 Not Allowed
Server: Microsoft-Azure-Application-Gateway/v2
Date: Mon, 02 Nov 2020 14:47:50 GMT
Content-Type: text/html
Content-Length: 183
Connection: close
Also to me the fact that the TRACE does not contain as many headers as the DELETE is a proof that the call will not reach the web server (which is fine with me) but then I expect the application gateway to fire the same rewrite rule as for any other method.
I also tried to remove the header instead of setting it to "Unknown" but this has the same effect (the header is removed on all methods except TRACE).
Trace method is not yet added to the list. We have this in our road map but with no ETA. Please follow Azure Updates page for further updates.
Visitors to a website get 500 Internal Server error after browsing for a bit due to a tracking cookie that pushes the overall cookie size for our domain to over 4kb (it's a page view cookie so it appends the page name each time you visit a new page).
I can reproduce the issue using curl with a very large cookie payload. In doing this I've been able to verify where exactly the 500 is coming from (we go from Cloudflare to Varnish to the backend webserver). I've verified that the requests that fail don't make it to the webserver, so I believe Varnish is the one serving up the 500s. I have also watched the varnishlog and seen the 500s come through.
This is an example response from the varnishlog
-- VCL_return hash
-- VCL_call HASH
-- VCL_return lookup
-- Hit 57254162
-- VCL_call HIT
-- VCL_return deliver
-- RespProtocol HTTP/1.1
-- RespStatus 200
-- RespReason OK
-- RespHeader X-Powered-By: Express
-- RespHeader Date: Thu, 01 Aug 2019 23:05:52 GMT
-- RespHeader Content-Type: application/json; charset=utf-8
-- RespHeader Content-Length: 1174
-- RespHeader X-Varnish: 57156196 57519178
-- RespHeader Age: 86
-- RespHeader Via: 1.1 varnish-v4
-- VCL_call DELIVER
-- RespHeader X-Cache: HIT
-- RespUnset X-Powered-By: Express
-- VCL_return deliver
-- Timestamp Process: 1564700838.564547 0.000354 0.000354
-- RespHeader Accept-Ranges: bytes
-- Debug "RES_MODE 2"
-- RespHeader Connection: keep-alive
-- Error workspace_client overflow
-- RespProtocol HTTP/1.1
-- RespStatus 500
-- RespReason Internal Server Error
-- Timestamp Resp: 1564700838.564580 0.000387 0.000033
-- ReqAcct 10063 0 10063 0 0 0
-- End
Here is what I'd added to the vcl_recv section to remove the offending cookie
set req.http.Cookie = regsuball(req.http.Cookie, "_loc_[^;]+(; )?", "");
I don't understand what the significance is of two RespStatus entries here. Why is it 200, and then 500? I've also noticed that if I use curl, which is using HTTP/1.1 I get the 500, but if I use HTTPie, which uses HTTP/2, I get a 200. Is that expected? Would Varnish handle the cookie size differently depending on the http version?
*Edited: I think I've figured out that the difference in the two response statuses are that one is the delivery of the content to varnish, and the second is the delivery of the content to the client.
As the log says, the workspace is too small to accommodate the transaction (headers, notably), try increasing it:
varnishadm param.set workspace_client 128k
For a long explanation: varnish uses a "worspace" for each transaction. This is a chunk of memory used to allocate data, and the whole chunk is wiped out at the end of the transaction. The headers notably are copied into the workspace, and everytime to add or modify a header, it goes there too.
Ths issue here is that you don't have enough space. Earlier version would just panic, but it's now smarter and just produces a synthetic response with a 500 status. The trick is that it realizes the lack of workspace after the initial response has been copied, so you see both responses in the log.
I am using the following API:
https://learn.microsoft.com/en-us/rest/api/compute/virtualmachines/delete
When trying to delete a VM which does not exist, I am given this response:
Response Code: 204
Headers-
cache-control: no-cache
expires: -1
pragma: no-cache
x-ms-correlation-request-id: 0bda7be7-6f2a-4202-9565-04d16c210606
x-ms-ratelimit-remaining-subscription-deletes: 14996
x-ms-request-id: 0bda7be7-6f2a-4202-9565-04d16c210606
x-ms-routing-request-id: WESTINDIA:20181223T044056Z:0bda7be7-6f2a-4202-9565-04d16c210606
Body: null
Shouldn't ideally a HTTP 404 be returned?
I suggest you take a look at Track asynchronous Azure operations to better understand the flow of execution when using Azure's management APIs.
As far as I understand, you are getting a 204 because the operation doesn't complete immediately. If you want to check the operation's state and end result, you need to query for it using methods described in the above link.
Update
After trying the operation on one of my subscriptions, looking at portal's activity log, it seems that the operation is being logged as "Succeeded". I'm afraid that the only way to know if a VM exists or not, is by trying to query for its info.
I also think, that in previous versions of the API a 404 was being returned in case the VM was not found, but for some reason it was changed (maybe because if it is not found then it already in a "deleted state").
Hope it helps!
I am trying to make a geocode request against the local.yahooapis.com geocode interface. This was working yesterday, with the same AppID, and a hardcoded address. Now I have broken up the query string and programmatically filled it from a database. the api returns a 403 - Forbidden error. I'm not sure if I have hit some throttling restrictions, or messed up my request in refactoring.
Request, with "MY_APP_ID" subbed out:
Warning: file_get_contents(http://local.yahooapis.com/MapsService/V1/geocode?appid=MY_APP_ID&street=6727+N+5TH+ST&city=PHILADELPHIA&state=PA&output=php) [function.file-get-contents]: failed to open stream: HTTP request failed! HTTP/1.1 403 Forbidden
And the wireshark of the entire back and forth:
GET /MapsService/V1/geocode?appid=MY_APP_ID&street=BOX+269&city=TOUGHKENAMON&state=PA&output=php HTTP/1.0
Host: local.yahooapis.com
HTTP/1.1 403 Forbidden
Date: Mon, 19 Jul 2010 14:46:42 GMT
P3P: policyref="http://info.yahoo.com/w3c/p3p.xml", CP="CAO DSP COR CUR ADM DEV TAI PSA PSD IVAi IVDi CONi TELo OTPi OUR DELi SAMi OTRi UNRi PUBi IND PHY ONL UNI PUR FIN COM NAV INT DEM CNT STA POL HEA PRE LOC GOV"
Connection: close
Content-Type: text/html; charset=iso-8859-1
<!doctype html public "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<html><head><title>Yahoo! - 403 Forbidden</title><style>
/* nn4 hide */
/*/*/
body {font:small/1.2em arial,helvetica,clean,sans-serif;font:x-small;text-align:center;}table {font-size:inherit;font:x-small;}
html>body {font:83%/1.2em arial,helvetica,clean,sans-serif;}input {font-size:100%;vertical-align:middle;}p, form {margin:0;padding:0;}
p {padding-bottom:6px;margin-bottom:10px;}#doc {width:48.5em;margin:0 auto;border:1px solid #fff;text-align:center;}#ygma {text-align:right;margin-bottom:53px}
#ygma img {float:left;}#ygma div {border-bottom:1px solid #ccc;padding-bottom:8px;margin-left:152px;}#bd {clear:both;text-align:left;width:75%;margin:0 auto 20px;}
h1 {font-size:135%;text-align:center;margin:0 0 15px;}legend {display:none;}fieldset {border:0 solid #fff;padding:.8em 0 .8em 4.5em;}
form {position:relative;background:#eee;margin-bottom:15px;border:1px solid #ccc;border-width:1px 0;}
#s1p {width:15em;margin-right:.1em;}
form span {position:absolute;left:70%;top:.8em;}form a {font:78%/1.2em arial;display:block;padding-left:.8em;white-space:nowrap;background: url(http://us.i1.yimg.com/us.yimg.com/i/s/bullet.gif) no-repeat left center;}
form .sep {display:none;}.more {text-align:center;}#ft {padding-top:10px;border-top:1px solid #999;}#ft p {text-align:center;font:78% arial;}
/* end nn4 hide */
</style></head>
<body><div id="doc">
<div id="ygma"><a href="http://us.rd.yahoo.com/403/*http://www.yahoo.com"><img
src=http://us.i1.yimg.com/us.yimg.com/i/yahoo.gif
width=147 height=31 border=0 alt="Yahoo!"></a><div>Yahoo!
- Help</div></div>
<div id="bd"><h1>Sorry, Forbidden.</h1>
You don't have permission to access this URL on this server.<P>
<P>Additionally, a 404 Not Found
error was encountered while trying to use an ErrorDocument to handle the request.
<p>Please check the URL for proper spelling and capitalization. If
you're having trouble locating a destination on Yahoo!, try visiting the
<strong><a
href="http://us.rd.yahoo.com/403/*http://www.yahoo.com">Yahoo! home
page</a></strong> or look through a list of <strong><a
href="http://us.rd.yahoo.com/403/*http://docs.yahoo.com/docs/family/more/">Yahoo!'s
online services</a></strong>. Also, you may find what you're looking for
if you try searching below.</p>
<form name="s1" action="http://us.rd.yahoo.com/403/*-http://search.yahoo.com/search"><fieldset>
<legend><label for
Can you identify what I am doing wrong, or tell me where I can check my AppID for any new restrictions?
Update:
I tried with a brand new appid. I used a 5 second sleep in the script, and only made 3 requests. The very first request failed. No idea what is causing this problem now.
Warning: file_get_contents(http://local.yahooapis.com/MapsService/V1/geocode?appid=orQG_ZLV34EmNvmFaIKpOd5RSu1aBsDEfoxNeJBFhr5VUM5dItKbyXLjoMYi0Q--&street=6727+N+5TH+ST&city=PHILADELPHIA&state=PA&output=php) [function.file-get-contents]: failed to open stream: HTTP request failed! HTTP/1.1 403 Forbidden in C:\wamp\www\Smartphone\updategeo.php on line 23
1
Warning: file_get_contents(http://local.yahooapis.com/MapsService/V1/geocode?appid=orQG_ZLV34EmNvmFaIKpOd5RSu1aBsDEfoxNeJBFhr5VUM5dItKbyXLjoMYi0Q--&street=7400+OXFORD+AVE&city=PHILADELPHIA&state=PA&output=php) [function.file-get-contents]: failed to open stream: HTTP request failed! HTTP/1.1 403 Forbidden in C:\wamp\www\Smartphone\updategeo.php on line 23
2
Warning: file_get_contents(http://local.yahooapis.com/MapsService/V1/geocode?appid=orQG_ZLV34EmNvmFaIKpOd5RSu1aBsDEfoxNeJBFhr5VUM5dItKbyXLjoMYi0Q--&street=2+W+FOURTH+ST&city=BRIDGEPORT&state=PA&output=php) [function.file-get-contents]: failed to open stream: HTTP request failed! HTTP/1.1 403 Forbidden in C:\wamp\www\Smartphone\updategeo.php on line 23
3
Edit again: my best guess is that since im working on a dev box, and the appId was generated for a different domain, its rejecting it. How can i determine if that is correct? This doesnt make 100% sense to me though, as this code did work at some point.
I've seen this too. Happened when I made a change to my app that increased the volume of
Yahoo! API calls, and is only happening for requests from my app's server. I suspect you (and I) exceeded the daily volumes permitted and are blacklisted by IP address. I can still make calls from my dev box with the same api key.
I hope we just get whitelisted again after a day.
The Yahoo! dev support forum for this API is at: http://developer.yahoo.net/forum/index.php?showforum=114