When I look at the Network tab in Opera Dragonfly, I'm not seeing POSTEd parameters or the RESPONSE content. Here's what I see:
Raw Response
HTTP/1.1 200 OK
Server: Microsoft-IIS/5.1
Date: Thu, 15 Jul 2010 12:43:19 GMT
X-Powered-By: ASP.NET
X-AspNet-Version: 2.0.50727
Cache-Control: no-cache
Pragma: no-cache
Expires: -1
Content-Type: text/html; charset=utf-8
Content-Length: 22320
In Dragonfly, is there a way to examine the parameters posted to the server and the actual response from the server?
The ability for Opera Dragonfly to get this information from the Opera rendering engine (Presto) should be included in Opera 11. We are currently working on implementing the client side code in Opera Dragonfly to support this and other Network Inspector features, such as editing headers and replaying requests.
EDIT:
As of July 2011 (Opera Dragonfly 1.1) it is possible.
To see POST parameters in Opera Dragonfly click on Network tab followed by Network log subtab. NOTE: It requires reloading the page, if the page was already loaded while opening Opera Dragonfly.
Not yet. Microsoft Fiddler HTTP debugger is a good replacement if you have an OS to run it on.
Related
I am a web developer,I used to do some updates on website developed in ASP .NET MVC 4.0
Recently we hosted eCommerce website on IIS 10.The website was running very slow, so I had to work for speed optimization, I have only work with images and file compression.
I also use Google web master tools for optimization, during optimization mostly we get 500 internal server error, some urls showing which has not been created yet.
Unfortunately, we are getting 500 error while proceed to Checkout Now. I am not able to figure out why i am getting 500 error? I didn't modify anything in Model and Controller, but i do some changes in View.
Here we proceed to Check Out Now.https://www.preservawellness.com/shoppingcart/cart
Here the page is redirected to Payment options such as Net banking, Credit/debit, PayPal, Paytm
https://www.preservawellness.com/ShoppingCart/OrderReview?subscriptionid=&Ptype=online&uid=282&Ctype=P
When we click on "Place Order" Button The server returns 500 error which we are not able to diagnose. Below is the url after processing request(Place Order button) we are getting internal server error.
https://www.preservawellness.com/ShoppingCart/ProcessToPayment/397
Below is the page error details, we found on Chrome Developer Console(Network)
**Request URL:** https://www.preservawellness.com/ShoppingCart/ProcessToPayment/398
Request Method: GET
Status Code: 500
Remote Address: 103.35.123.182:443
Referrer Policy: no-referrer-when-downgrade
cache-control: private
content-length: 125200
content-type: text/html; charset=utf-8
date: Thu, 13 Dec 2018 06:11:23 GMT
server: Microsoft-IIS/10.0
**status: 500**
x-aspnet-version: 4.0.30319
x-aspnetmvc-version: 4.0
x-powered-by: ASP.NET
:authority: www.preservawellness.com
:**method: GET**
:path: /ShoppingCart/ProcessToPayment/398
:scheme: https
accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,*/*;q=0.8
accept-encoding: gzip, deflate, br
accept-language: en-US,en;q=0.9
cache-control: max-age=0
cookie: G_ENABLED_IDPS=google; _ga=GA1.2.1980725648.1544503724; iztoken=; __unam=31c7a61-1679bfb9e68-35018d90-1; UserActivity=ProductID=54,34,35,15,23; _gid=GA1.2.898897304.1544674779; _fbp=fb.1.1544674779709.1169244464; izstatus=1; ASP.NET_SessionId=13itm5jbgar1edaviq1id2fl; __RequestVerificationToken=yg9rIfvgB1xkV_9RGhApwCQydRIbnLFwgh9VLplBUhKnjKmbvDu-Ct2AdANFxppppwPwAN-olzYQUf7sbQrQQ0Sa9KWl-NgPMYzFjI8lypCwrDhqpL8uNsFzK9Y5GeA1fyjSgntOPqluH6E1S3HQvQ2; ispopupopen=30; ispopupopens=10; _gat_gtag_UA_92955094_1=1
referer: https://www.preservawellness.com/ShoppingCart/OrderReview?subscriptionid=&Ptype=online&uid=282&Ctype=P
upgrade-insecure-requests: 1
user-agent: Mozilla/5.0 (iPhone; CPU iPhone OS 11_0 like Mac OS X) AppleWebKit/604.1.38 (KHTML, like Gecko) Version/11.0 Mobile/15A372 Safari/604.1
Error Page:
page with error
IIS must be using * instead of ip address and or host header
I'm trying to show secure images for end user as a div with background (css background-image: url(...)) I have cross-domain configuration where my AngularJS client application is deployed on S3 bucket and server-side (Ruby-on-Rails) is deployed on heroku under different domain name.
All normal browsers are sending the auth cookie(which was set after authentication) within the image request so that server can understand if user has access to that particular image and response according to that.
But somehow IE10 and IE11 doesn't send any cookies on cross-origin requests. But when I set up both servers on the same machine (only ports are different) - everything works fine.
Can anyone help me with this issue?
Update:
Request headers:
Accept image/png, image/svg+xml, image/*;q=0.8, /;q=0.5
Referer my_referrer_url
Accept-Language ru-RU,en-US;q=0.5
User-Agent Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.1; WOW64; Trident/6.0)
Accept-Encoding gzip, deflate
Host my_heroku_serverside_url
DNT 1
Connection Keep-Alive`
Response headers:
Response HTTP/1.1 401 Unauthorized
Server Cowboy
Date Thu, 26 Feb 2015 22:24:04 GMT
Connection keep-alive
Strict-Transport-Security max-age=31536000
X-Frame-Options SAMEORIGIN
X-Xss-Protection 1; mode=block
X-Content-Type-Options nosniff
Content-Type text/html; charset=utf-8
Cache-Control no-cache
X-Request-Id df2154b6-5c6f-4534-bff0-094576359b78
X-Runtime 0.005919
Transfer-Encoding chunked
Via 1.1 vegur
No need to use Restangular you can specify widthCredentials for every $http request like this:
.config(function ($routeProvider, $httpProvider) {
$httpProvider.defaults.withCredentials = true;
I previously answered a similar question like it here: $http doesn't send cookie in Requests
I had a similar issue a few months ago and I solved it using AngularJS with Restangular and then setting, in my JS app configuration:
angular.module('myApp', ['restangular'])
.config(['RestangularProvider', function (RestangularProvider) {
RestangularProvider.setBaseUrl(serverUrl);
RestangularProvider.setDefaultHttpFields({
'withCredentials': true
});
}]);
Everything worked just fine.
We have recently begun moving some of our ASP.NET MVC websites from our own managed environment to Azure. One of the issues we have seen is that client side caching does not seem to be working properly when delivering dynamically created content. Specifically, the cache-related headers added to the HTTP response in code are stripped.
For example, the following headers are returned on the old environment in order to advise the client that the content may be cached:
Cache-Control: public, max-age=31533144
Content-Disposition: attachment; filename=picture.png
Content-Length: 64326
Content-Type: image/png
Date: Tue, 23 Jul 2013 15:44:57 GMT
Etag: "845D3DD630A7AEF5B68EA7A09B670A4D"
Expires: Fri, 23 Aug 2013 14:57:22 GMT
Last-Modified: Tue, 23 Jul 2013 14:57:22 GMT
Server: Microsoft-IIS/7.5
But on Azure, the following headers are returned instead:
Content-Disposition: attachment; filename=picture.png
Content-Length: 64326
Content-Type: image/png
Date: Tue, 23 Jul 2013 15:44:57 GMT
Server: Microsoft-IIS/8.0
X-Powered-By: ARR/2.5, ASP.NET
As you can see, the Cache-Control, Etag, Expires and Last-Modified headers have been dropped.
I have seen a number of suggestions regarding the caching of static content, but I do not believe that these will help in this case. Is it a case that the structure of the Azure CDN prevents caching in this way? Should Azure blobs be used instead? Is there a basic configuration change that may have been overlooked?
Thanks in advance
X-Powered-By: ARR/2.5, ASP.NET
ARR stands for Application Request Routing.
Go to inetmgr UI and click on the server name and you will find the option 'Application Request Routing Cache'.
You'll see 'Cache configuration', check options there. Also, check 'Cache control rules' there. Click 'Add rule...' and try play around with it.
Azure Websites site behind ARR. ARR will drop some HTTP headers and add its own, it's not something you have direct control over. A better fit for your problem may be using Azure CDN for static content. This does pay attention to and use the cache control headers. You can run a CDN on top of a blob storage container.
I'm using IIS6 and Windows 2003 server where I enabled gzip compression for my MVC project. I thought I got it working, but once I tested in IE it did not work. I feels like it does not recognize the gzip compression or something. It works fine in Fire Fox (version 13).
Do I need to configure something?
I do a HTTP post to get some data.
Header:
HTTP/1.1 200 OK
Cache-Control: private
Date: Tue, 13 Nov 2012 21:33:19 GMT
Content-Type: text/html; charset=utf-8
Server: Microsoft-IIS/6.0
X-Powered-By: ASP.NET
X-AspNet-Version: 4.0.30319
X-AspNetMvc-Version: 3.0
Content-Encoding: gzip
Vary: Accept-Encoding
Transfer-Encoding: chunked
If you need anything else please let know.
Thanks
IIS does not perform HTTP compression on "dynamic" resources by default, only "static" files. This is because it caches the compressed results in IIS's temporary files directory, whereas dynamic content compression means it has to compress it every time its requested, which can burden the server if it's handling a lot of requests.
I also note that you're using IIS6 which is very antiquated at this point, but check out the documentation here: http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/502ef631-3695-4616-b268-cbe7cf1351ce.mspx?mfr=true
I am running into an issue playing a properly encoded video on an iOS device. Here is some background/information:
We are using jwPlayer for playback
The video plays great through flash and HTML5
The video was encoded through zencoder's default settings
We are serving video from the same server which works on iOS devices (but that site is not Sitecore)
The video plays on my iPad when synced through dropbox
Through some investigation and some help from the great support staff at Zencoder, we think the issue may be related to the headers (top is the video that does not work, bottom works fine):
$ curl -I http://fraternity.computol.com/~/media/Fraternity/mp4/leadership_zen.mp4
HTTP/1.1 200 OK
Date: Wed, 29 Jun 2011 16:30:29 GMT
Server: Microsoft-IIS/6.0
X-Powered-By: ASP.NET
X-AspNet-Version: 2.0.50727
Content-Disposition: attachment; filename="leadership_zen.mp4"
Transfer-Encoding: chunked
Set-Cookie: fraternity#sc_wede=1; path=/
Cache-Control: public, max-age=604800
Expires: Wed, 06 Jul 2011 16:30:29 GMT
Last-Modified: Wed, 29 Jun 2011 16:28:26 GMT
ETag: 9cba9593424645bfb372a01bfe522f97
Content-Type: application/octet-stream
$ curl -I http://www.rhythmonthevine.org/videos/SHR_ROTV_Dierks_v02.mp4
HTTP/1.1 200 OK
Content-Length: 16091772
Content-Type: video/mpeg
Last-Modified: Thu, 24 Mar 2011 14:05:49 GMT
Accept-Ranges: bytes
ETag: "8374ff932ceacb1:335c"
Server: Microsoft-IIS/6.0
X-Powered-By: ASP.NET
Date: Wed, 29 Jun 2011 16:30:32 GMT
Does anyone have any idea whether this issue is actually header related? If so, is there a way to get sitecore to serve the media properly?
Edit: Also, if it makes any difference at all, we are on IIS6.
Edit: The particularly troublesome differences are:
Transfer-Encoding (the one that is not working is chunked)
Content length (missing on the top video)
Content type (I think this is the big one. I have the proper mime type setup in sitecore - I don't what Sitecore is not serving it)
I had a similar issue which I posted on the SDN. It was about getting videos to play on the iPad and be served from the Media Library. The useful response was that the Sitecore media request HTTP handler (sitecore_media.ashx) delivers the media responses in chunk (HTTP transport, Transfer-Encoding: chunked), which conflicts with the Apple protocol (response must be delivered in one chunk to the client). You may want to try to see if you can override the MediaRequestHandler.
I ran into the same issue, and was able to get past it through a few things:
I added the mime-type to MimeType.config as below:
<mediaType extensions="mp4"><mimeType>video/mp4</mimeType></mediaType>
Went into the item in the Media Library, and changed the Mime Type of the Item to be "video/mp4".
Went into the server, and deleted all files under "C:\inetpub\wwwroot\Sitecore62\Website\App_Data\MediaCache"
I had different header values under Curl, but the wrong mime-type was consistent with yours. Once I did all of the above the mime-type was returned properly and the video played - HTML below:
<video class="video-js" width="640" height="360" autoplay controls loop>
<source src="http://<server>/~/media/client/videos/video.mp4" type="video/mp4" />
</video>
I gave Mark a +1 but I'll offer an alternative as well, could you work around the issue by serving the content through mirroring on a CDN (such as Akamai) or host it entirely on a video CDN (such as Bits on the Run (http://www.longtailvideo.com/bits-on-the-run/)?
This would likely result in lower bandwidth cost and better performance as well, rather than constantly serving video from Sitecore.