Chrome block requests

Question

I am facing unusual issue in Chrome. it is blocking a few requests and returns following:

min.php?g=oxp-js&v=2.8.11 /openx/www/admin/assets GET (failed) dashboard.php:29 Parser

On further investigation it says:

Chrome provisional headers are shown

Same page works fine on other browsers.

Response Headers are given Below

Request URL:http://localhost/openx/www/admin/assets/min.php?g=oxp-css-ltr&v=2.8.11
Request Headers CAUTION: Provisional headers are shown.
Accept:text/css,*/*;q=0.1
Cache-Control:no-cache
Pragma:no-cache
Referer:http://localhost/openx/www/admin/dashboard.php
User-Agent:Mozilla/5.0 (Macintosh; Intel Mac OS X 10_6_8) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/32.0.1700.41 Safari/537.36
Query String Parametersview sourceview URL encoded
g:oxp-css-ltr
v:2.8.11

Below is the Buggy LInk that is not executed well by Chrome when executed as a part of a web page

[link rel="stylesheet" type="text/css" href="http://localhost/openx/www/admin/assets/min.php?g=oxp-css-ltr&v=2.8.11]

But when I access directly, it returns Headers properly. I can't figure out why is it like that?.

Update

I used LIVE HTTPHEADERS extension to grab the content, given below:

GET /openx/www/admin/assets/min.php?g=oxp-css-ltr&v=2.8.11 HTTP/1.1
Host: localhost
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
Accept-Encoding: gzip,deflate,sdch
Accept-Language: en-US,en;q=0.8,ur;q=0.6
Cache-Control: no-cache
Cookie: PHPSESSID=87eb59b22ac0ce0d57ecf1e422a412a7; ox_install_session_id=341ef9a68cffdbd9b47d6076e0f12d40; sessionID=b7ccb4b31bc58e5958ec84d44110100f
Pragma: no-cache
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_6_8) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/32.0.1700.41 Safari/537.36

HTTP/1.1 200 OK
Cache-Control: max-age=1800, public, must-revalidate
Connection: Keep-Alive
Content-Encoding: deflate
Content-Length: 15116
Content-Type: text/css; charset=UTF-8
Date: Wed, 11 Dec 2013 16:40:49 GMT
ETag: "1375816424pub"
Expires: Wed, 11 Dec 2013 17:10:49 GMT
Keep-Alive: timeout=5, max=100
Last-Modified: Tue, 06 Aug 2013 19:13:44 GMT
Server: Apache/2.2.25 (Unix) mod_ssl/2.2.25 OpenSSL/0.9.8y DAV/2 PHP/5.5.3
Vary: Accept-Encoding
X-Powered-By: PHP/5.5.3

Spindly

can you use a tool like fiddler or charles to capture the full HTTP exchange and post that here for diagnosis? you havent given us much to go on – Wellheeled

I can copy Google Developer tools..wait – Spindly

@RobertLevy it's done. Please check updated Question – Spindly

you are trying to determine if this is a chrome bug. use an outside tool to capture both the request and response – Wellheeled

@RobertLevy I am on mac.. Charles seems paid and need loads of configuration. I tried LIVEHTTPHEADERS extension, it just fetched REQUEST headers, No RESPONSE header was found. – Spindly

@RobertLevy <link rel="stylesheet" type="text/css" href="localhost/openx/www/admin/assets/…"> this links is being blocked. Same link works fine on other browsers – Spindly

@RobertLevy I updated further. – Spindly

Answer 1

I had a similar problem today loading jShowOff jQuery's plugin. In my case the resource was being blocked by a Chrome extension (AdBlock). I couldn't see the problem in other browsers because AdBloc was installed in Chrome only.

The CAUTION: Provisional headers are shown. message is shown in DevTools because the headers you are seeing are not the actual headers sent to the server. In this case no headers were sent, because the resource was blocked before doing the request. The comments in this issue has additional details that explain the CAUTION message.

You probably have an extension that's blocking your URL.

Cervicitis

Answer 2

I ran into a similar issue this week. For few Chrome and Safari users, there was a huge delay in loading the web application. My application is based on Spring MVC framework and is deployed on Tomcat 7 server. I found that the issue was with server's HTTP Connector attibute : maxKeepAliveRequests.From the Tomcat's HTTP Connector documentation found here,I understood that this attribute determines the maximum number of HTTP requests which can be pipelined until the connection is closed by the server. In your case, I see the header attribute is set to "Keep-Alive: timeout=5, max=100". Please check the corresponding connector value in your server and take appropriate action.

Conidium

Answer 3

The form I was having this issue has this attribute enctype="multipart/form-data".

Removing this attribute using the Chrome Dev Tools console resolved this.

Intake