I have an app wich download a file from a server, receiving it in tcp packets and I want to found the path of file on the server. With wireshark I read in the first packet some information like date, domain, file name and as path I read path=/ but it isn't in domain.com/filename (404). Is there any way to get the real path where the file is on the server?
edit:
All I found comprehensible in the first packet:
HTTP/1.1 200 OK
Date: Sat, 30 Aug 2014 14:35:55 GMT
Server: Apache/2.2.3 (CentOS)
X-Powered-By: PHP/5.3.24
Set-Cookie: frontend=m90hqgtsu70hk9pprd39sllqk4; expires=Sat, 30-Aug-2014 25:35:55 GMT; path=/; domain=www.exaple.com; HttpOnly
Content-Disposition: attachment; filename="xxx.y"
Content-Length: 46458848
Connection: close
Content-Type: application/octet-stream
The request:
GET /index.php/rest/server?method=download&sessionId=xxx&userId=a#a.com&deviceToken=xxx&sku=filename&version=2
HTTP/1.1
Connection: Keep-Alive
Accept Encoding: gzip
Accept-Language: it-IT,en,*
User-Agent: Mozilla/5.0
Host: www.domain.com
The file is being downloaded using HTTP (read RFC 2616). The packet you are looking at is a response. The domain and path information you are looking for is not in the response, it is in the request instead:
GET /index.php/rest/server?method=download&sessionId=xxx&userId=a#a.com&deviceToken=xxx&sku=filename&version=2 HTTP/1.1
Connection: Keep-Alive
Accept Encoding: gzip
Accept-Language: it-IT,en,*
User-Agent: Mozilla/5.0
Host: www.domain.com
So the URL to request the file would be http://www.domain.com/index.php/rest/server?method=download&sessionId=xxx&userId=a#a.com&deviceToken=xxx&sku=filename&version=2.
The filename you see in the response is the actual filename for the file. But not all responses will include such a filename, so be prepared for that. If there is no Content-Disposition header (or it does not have a filename attribute), look for a name attribute in the Content-Type header. If none, you will have to parse the request URL (see RFC 3986) looking for a filename in its Path component (in the above URL, that is /index.php/rest/server).
The domain and path pieces you see in the response are not related to the file at all. They belong to a cookie (see RFC 6265) that is used to persist server-side data between HTTP requests.
If the server does not voluntarily provide the path you are looking for there is no way to find out. The file it sends might not even be on disk. It might be generated data or data cached in application memory.
If the response does not contain the path (and that is unlikely because no server I know of would send it) you can't do anything to find it.
Related
I have recently started using libCurl for client-server communication project where I use libcurl in the client side. We used to use WinHTTP, but did not find a way to add TLS 1.3 backward compatibility with earlier windows versions.
The cnonce is part of Digest Authentication headers.
When my project was earier using WinHTTP, the cnonce used to be hexadecimal.
Eg:
cnonce="a01e21c2a827ec6d3d9b6e1745ca8a0b"
HTTP Header
Server to client:
HTTP/1.1 401 Unauthorized
Content-Length: 26
WWW-Authenticate: Negotiate
WWW-Authenticate: Digest realm="a2ffc77914d6e791d", qop="auth",nonce="3f3da4b94e249058", opaque ="3b3542c"
Client to Server:
POST /wsman HTTP/1.1
Connection: Keep-Alive
Content-Type: application/soap+xml;charset=UTF-8
User-Agent: Openwsman
Content-Length: 889
Host: 10.138.141.178:623
Authorization: Digest username="PostMan",realm="a2ffc77914d6e791d",nonce="3f3da4b94e249058",uri="/wsman",cnonce="a01e21c2a827ec6d3d9b6e1745ca8a0b",nc=00000001,response="9dd37ef997ef332e46dff0f868b3de89",qop="auth",opaque="3b3542c"
When I look at the HTTP header I find that the cnonce is alphanumeric with Curl.
Eg:
cnonce="NDlmYTM0ZjVlM2IzNTNhMDNiNDk0MzQ1MzdlYmFlMzA="
HTTP Header
Server to Client
HTTP/1.1 401 Unauthorized
Content-Length: 0
Connection: Keep-Alive
Content-Type: application/soap+xml;charset=UTF-8
WWW-Authenticate: Digest realm="a2ffc77914d6e791d", nonce="5bf1156647e8eb42", algorithm="MD5", qop="auth", opaque="661d9eae", userhash=true
Client to Server
POST /wsman HTTP/1.1
Host: blr-5cg64728l6.amd.com:623
Authorization: Digest username="PostMan", realm="a2ffc77914d6e791d", nonce="5bf1156647e8eb42", uri="/wsman", cnonce="NDlmYTM0ZjVlM2IzNTNhMDNiNDk0MzQ1MzdlYmFlMzA=", nc=00000001, qop=auth, response="6847e465c9c90b40264b736070f721da", opaque="661d9eae", algorithm=MD5, userhash=true
Accept: */*
Content-Type: application/soap+xml;charset=UTF-8
User-Agent: Openwsman
Content-Length: 897
With alpha numeric cnonce the server is not responding back consistantly. Is there a way to specify in libcurl to generate hexadecimal cnonce - explicitly?
Note: To avoid security risk, the fields have been modified in the headers above.
I am using LibCurl: 7.73
with OpenSSL TLS backend: 1.1.1h
I'm creating a simple proxy server and I've run into an issue with getting responses back from a website.
I've set up my server to accept connections on a specified port that gets connected to through the browser proxy config. The server is able to receive the request, connect to the specified website, send the request, and receive a reply.
I'm forwarding the request from the browser to the website without modification, but the replies I receive are always 404 errors.
This is the request I'm fowarding to the website, there is a \r\n after every line and \r\n\r\n after the final line.
GET http://www.mywebpage.com/ HTTP/1.1
Host: www.mywebpage.com
User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:66.0) Gecko/20100101 Firefox/66.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Connection: keep-alive
Cookie: __utma=1.35811746.1525489860.1537250282.1539467023.3; __utmz=1.1537250282.2.2.utmcsr=google|utmccn=(organic)|utmcmd=organic|utmctr=(not%20provided); _fbp=fb.1.1553849756364.1600689742
Upgrade-Insecure-Requests: 1
My send receive code looks like this.
sendError = send(serverSock, requestString , strlen(requestString) , 0 );
returnedSize = recv(serverSock, buffer, sizeof(buffer), 0);
I'm forwarding the request from the browser to the website without modification
...
GET http://www.mywebpage.com/ HTTP/1.1
The absolute URL you use in your request target should only be used for proxies. Normal servers expect the origin form, i.e. only the path and optional query but not the full URL. Method, host and port should thus be stripped:
GET / HTTP/1.1
For a responsive Website I prefer Dynamic Serving, But i don't know how it work the link is here
https://developers.google.com/webmasters/mobile-sites/mobile-seo/dynamic-serving
So i fount the solution use
GET /page-1 HTTP/1.1
Host: www.example.com
(...rest of HTTP request headers...)
HTTP/1.1 200 OK
Content-Type: text/html
Vary: User-Agent
Content-Length: 5710
(... rest of HTTP response headers...)
I have an AngularJS web app that accesses a .NET WebAPI server end. Authentication is implemented through the AngularJS-OAuth2 library. I have the app and the WebAPI hosted in localhost under two different port numbers. I have also enabled Microsoft.Owin.Cors package on the server end to handle cross-domain requests.
In Chrome, GET and POST requests return data to the front-end. By inspecting the traffic through Fiddler I could see that a pair of requests/responses are sent (preflight/OPTIONS + actual) and also the relevant CORS headers (including origin and Access-Control-* headers) in both the requests and the responses. All as expected.
However, in Internet Explorer, my GET requests return data through the $http service but the POST does not. I could inspect that there are no preflight requests or CORS headers (I think IE treats different ports as the same origin). In checking the POST request/response in IE through Fiddler I could observe that it returns HTTP status 200 but state of Aborted (with X-ABORTED-WHEN: SendingResponse flag set). I could also inspect the JSON response with the correct data returned.
I have also tried setting a high timeout to no avail. The $http call looks like this:
return $http.post(apiUrl + "/search", service.getParameters(), { timeout: 600000 })
.success(function (data) {...
Fiddler shows something like this for the IE POST request:
Also (only) in IE, an unintentional page refresh is also triggered with the same button click as this POST operation.
Why does Internet Explorer abort only the POST requests when the correct data is also returned to the client and when Chrome does not have any issues at all?
Additional Information
Request:
POST https://localhost:44321/api//search HTTP/1.1
Content-Type: application/json;charset=utf-8
Accept: application/json, text/plain, */*
Authorization: Bearer <token>
Referer: https://localhost:44322/search
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; Trident/7.0; rv:11.0) like Gecko
Host: localhost:44321
Content-Length: 202
DNT: 1
Connection: Keep-Alive
Cache-Control: no-cache
Cookie: .ASPXANONYMOUS=<cookie>
Reponse:
HTTP/1.1 200 OK
Cache-Control: no-cache
Pragma: no-cache
Content-Type: application/json; charset=utf-8
Expires: -1
Server: Microsoft-IIS/10.0
X-AspNet-Version: 4.0.30319
X-SourceFiles: <file>
X-Powered-By: ASP.NET
Date: Wed, 10 Feb 2016 13:43:45 GMT
Content-Length: 2284
Fiddler session properties:
SESSION STATE: Aborted.
Request Entity Size: 202 bytes.
Response Entity Size: 2284 bytes.
== FLAGS ==================
BitFlags: [IsHTTPS, ClientPipeReused, ServerPipeReused] 0x19
X-ABORTED-WHEN: SendingResponse
X-CLIENTIP: 127.0.0.1
X-CLIENTPORT: 41889
X-EGRESSPORT: 41890
X-HOSTIP: ::1
X-PROCESSINFO: avp:3584
X-RESPONSEBODYTRANSFERLENGTH: 2,284
X-SERVERSOCKET: REUSE ServerPipe#168
== TIMING INFO ============
ClientConnected: 19:13:42.408
ClientBeginRequest: 19:13:42.444
GotRequestHeaders: 19:13:42.444
ClientDoneRequest: 19:13:42.772
Determine Gateway: 0ms
DNS Lookup: 0ms
TCP/IP Connect: 0ms
HTTPS Handshake: 0ms
ServerConnected: 19:13:42.413
FiddlerBeginRequest: 19:13:42.772
ServerGotRequest: 19:13:42.772
ServerBeginResponse: 19:13:45.360
GotResponseHeaders: 19:13:45.360
ServerDoneResponse: 19:13:45.360
ClientBeginResponse: 19:13:45.360
ClientDoneResponse: 19:13:45.360
Overall Elapsed: 0:00:02.915
The response was buffered before delivery to the client.
== WININET CACHE INFO ============
This URL is not present in the WinINET cache. [Code: 2]
* Note: Data above shows WinINET's current cache state, not the state at the time of the request.
* Note: Data above shows WinINET's Medium Integrity (non-Protected Mode) cache only.
I believe you get bitten by the P3P policy requirement of IE here:
Internet Explorer supports a cookie-restricting privacy feature called P3P. Web developers often get tripped up by it because no other browser implements the P3P standard.
It seems similar to those QAs:
CORS request with IE11
CORS doesn't work with cookies in IE10
Internet Explorer 10 is ignoring XMLHttpRequest 'xhr.withCredentials = true'
Here's a blog post with an example how to send P3P information. Here's a document from Microsoft about P3P configuration
I'm trying to delete several object in batch using the documentation: Sending Batch Requests. Here is my request (<my_api_key> is the valid API key and other methods like list contents of a bucket work good, <my_bucket> is the placeholder for the exact bucket name):
POST /batch?key=<my_api_key>
host: www.googleapis.com
content-type:multipart/mixed; boundary="===============7330845974216740156=="
--===============7330845974216740156==
Content-Type: application/http
Content-Transfer-Encoding:binary
DELETE /storage/v1/b/<my_bucket>/o/James-Hetfield-happy.jpg
--===============7330845974216740156==
Here is the response:
access-control-allow-credentials:true
access-control-allow-origin:chrome-extension://fdmmgilgnpjigdojojpjoooidkmcomcm
access-control-expose-headers:Cache-Control,Content-Encoding,Content-Length,Content-Type,Date,Expires,Pragma,Server,Vary
alternate-protocol:443:quic,p=0.02
cache-control:no-cache, no-store, max-age=0, must-revalidate
content-encoding:gzip
content-length:33
content-type:text/html; charset=UTF-8
date:Tue, 10 Feb 2015 16:55:14 GMT
expires:Fri, 01 Jan 1990 00:00:00 GMT
pragma:no-cache
server:GSE
status:500 Internal Server Error
vary:Origin
vary:X-Origin
version:HTTP/1.1
x-content-type-options:nosniff
x-frame-options:SAMEORIGIN
x-xss-protection:1; mode=block
Unknown Error
When I send the following body:
--===============7330845974216740156==
DELETE /storage/v1/b/<my_bucket>/o/James-Hetfield-happy.jpg
--===============7330845974216740156==
I got 200 OK response with the body --batch_rTJhZwR1jHM_AAh2WtGp7ik-- but the file still exists.
Please advise proper format for sending batch delete requests using Google Cloud Storage JSON API.
My bad. When copy-pasting from examples, a spare space character appeared right after the header Content-Type: application/http. When I removed all spare characters in request's headers the batch delete worked good.
Conclusions: validate syntax of requests manually after copy-pasting.