How do you open HTML file in javascript? - javascript
So, firstly I'd like to specific that I'm aware of the following code
window.open(url);
which has worked very well for me in the past.
The problem this time is that I'm trying to open a html file that isn't online as such. The file itself is here "http://coynesresources.weebly.com/uploads/7/6/5/3/76537449/small.html" and when I try to use the following
window.open("http://coynesresources.weebly.com/uploads/7/6/5/3/76537449/small.html");
only allows me to download the HTML file, rather than open it in my browser. Any help would be greatly appreciated.
Try this
window.open("http://coynesresources.weebly.com/uploads/7/6/5/3/76537449/small.html", "windowName", "width=200,height=100",false);
more information see here
http://www.w3schools.com/jsref/met_win_open.asp
https://developer.mozilla.org/en-US/docs/Web/API/Window/open
You can't use direct ajax query for this url (crossdomain policy). So you must use proxy with jsonp.
See: Loading cross domain endpoint with jQuery AJAX
And working example for you:
http://jsbin.com/bahigodiru/1/edit?html,js,output
But it is not good solution. There are a lot of free hostings that you can use. Or use jsfiddle/jsbin (for jsbin you can get link to page without online editor: http://jsbin.com/bahigodiru/1/ )
weebly.com is a platform to create a site. You should not upload you html as file. You should add it's content as custom html: https://www.weebly.com/blog/file-upload-new-linker-custom-html-and-a-new-upgrade-process
I'm going to guess that you can't.
The issue is the server is returning a header that tells the browser to download it instead of display it
curl -v "http://coynesresources.weebly.com/uploads/7/6/5/3/76537449/small.html"
* Trying 199.34.228.54...
* Connected to coynesresources.weebly.com (199.34.228.54) port 80 (#0)
> GET /uploads/7/6/5/3/76537449/small.html HTTP/1.1
> Host: coynesresources.weebly.com
> User-Agent: curl/7.43.0
> Accept: */*
>
< HTTP/1.1 200 OK
< Server: nginx
< Date: Sat, 09 Jul 2016 19:17:29 GMT
< Content-Type: text/html
< Content-Length: 904
< Last-Modified: Sat, 09 Jul 2016 15:10:54 GMT
< Connection: keep-alive
< ETag: "578113fe-388"
< Expires: Sat, 16 Jul 2016 19:17:29 GMT
< Cache-Control: max-age=604800
< Content-Disposition: attachment
< Accept-Ranges: bytes
< X-W-DC: SFO
<
That Content-Disposition: attachment part tells the browser to download instead of display
See RFC 6266
4.2. Disposition Type
If the disposition type matches "attachment" (case-insensitively),
this indicates that the recipient should prompt the user to save the
response locally, rather than process it normally (as per its media
type).
Related
How to get metadata using BlockBlobClient.getProperties in azure storage javascript SDK for browser
I am trying to get the metadata for a particular blob using the azure storage javascript SDK. Here is my code:
private returnBlobMetadata(filename: string, container: string) {
const blobServiceClient = new BlobServiceClient(`${this.sasData.storageUri}?${this.sasData.storageAccessToken}`);
const containerClient = blobServiceClient.getContainerClient(container);
const blobClient = containerClient.getBlockBlobClient(filename);
return from(blobClient.getProperties());
}
When I subscribe to the output of this function I get a response. However, my metadata is empty, despite the metadata being present in the portal, every other entity is also empty. I also am able to receive the metadata when listing blobs within a container.
Here is my response:
Any help you could give me would be very much appreciated as I've been tearing my hair out at this one.
EDIT
On inspection of the headers, I can see that it is present there a x-ms-meta-filename however.
Accept-Ranges: bytes
Access-Control-Allow-Origin: *
Access-Control-Expose-Headers: content-length
Content-Length: 67961
Date: Tue, 28 Apr 2020 11:41:08 GMT
ETag: "0x8D7EB1A5E0E88CF"
Last-Modified: Tue, 28 Apr 2020 02:17:57 GMT
Server: Windows-Azure-Blob/1.0 Microsoft-HTTPAPI/2.0
x-ms-access-tier: Hot
x-ms-access-tier-inferred: true
x-ms-blob-type: BlockBlob
x-ms-client-request-id: **id**
x-ms-creation-time: Tue, 28 Apr 2020 01:50:06 GMT
x-ms-lease-state: available
x-ms-lease-status: unlocked
x-ms-meta-filename: Curriculum Vitae.pdf <-- this is what I want
x-ms-request-id: 4d87bf9c-901e-0089-5551-1d8136000000
x-ms-server-encrypted: true
x-ms-version: 2019-02-02
SOLVED If anyone else is suffering the same issue here is the answer. The expose headers option was not set in the azure portal. This meant that the headers were not exposed to the frontend and my application could not read them. When I set them to all this fixed my problem.
Stream video from dropbox? Possible byte-range issue
I'm using videojs to play videos hosted on Dropbox, but users report that it doesn't work on iPhones (iOS) and for some users the video doesn't play in their browser either half of the times.
1)
Anyone know if Dropbox has any bandwidth/connection limits on this? I'm intending on having top 10 users watching each link so it shouldn't be an issue.
2)
Anyone know if I should use raw=1 or dl=1 at the end of the links for embedded content from Dropbox?
3)
My googling has pointed me in the direction that the issue might be that Dropbox doesn't send byte-ranges, which is said to be necessary for iOS/Safari and even Chrome. In the example below, is there any way to find out if that is the case? I don't know where to look for the headers. Another lead told me to "make sure your app can follow redirects". Is that the same thing as the byte-range issue or how do I make sure of that?
NOTE: I tried to set up a snippet, but couldn't get it to work with external libraries. Can anyone kindly help me with that?
4)
If any of the above is the case, is there a way to alter something on the Dropbox side, or using PHP or any other techniques to fetch the link and present it differently?
Thank you!
var myPlayer = videojs('my-video');
<head>
<link href="http://vjs.zencdn.net/6.6.3/video-js.css" rel="stylesheet">
<!-- If you'd like to support IE8 -->
<script src="http://vjs.zencdn.net/ie8/1.1.2/videojs-ie8.min.js"></script>
</head>
<body>
<video id="my-video" class="video-js" controls preload="auto" width="854" height="480" poster="https://www.dropbox.com/s/3q2u7p0cep2c98x/bunny.jpg?raw=1" data-setup="{}">
<source src="https://www.dropbox.com/s/yo9nbii33pfwmtt/big_buck_bunny_480p_h264.mov?raw=1" type="video/mp4" />
<p class="vjs-no-js">
To view this video please enable JavaScript, and consider upgrading to a web browser that
supports HTML5 video
</p>
</video>
<script src="http://vjs.zencdn.net/6.6.3/video.js"></script>
</body>
Dropbox does have bandwidth limits for shared links. If shared links aren't working, that's one possible cause. You should check the error code for that. An error code of 429 indicates the link is banned for too much traffic. The limits are documented here: https://www.dropbox.com/help/security/banned-links#traffic If a link isn't currently banned though, it can be used to access file content. By default, shared links point to a preview page, so you will need to modify them. Using the URL parameters dl=1 or raw=1 is the right way to do so. In this case, raw=1 makes more sense. E.g.: https://www.dropbox.com/s/yo9nbii33pfwmtt/big_buck_bunny_480p_h264.mov?raw=1 Those are documented here: https://www.dropbox.com/help/desktop-web/force-download These modified shared links will return redirects though, so the client will have to follow them. The resulting links do support byte ranges though. Here's a sample of verbose output from curl, showing and following the redirect and with a byte range retrieval request working: (some irrelevant output redacted) $ curl -v -L "https://www.dropbox.com/s/yo9nbii33pfwmtt/big_buck_bunny_480p_h264.mov?raw=1" -H "Range:bytes=0-10" > GET /s/yo9nbii33pfwmtt/big_buck_bunny_480p_h264.mov?raw=1 HTTP/1.1 > User-Agent: curl/7.33.0 > Host: www.dropbox.com > Accept: */* > Range:bytes=0-10 > < HTTP/1.1 302 Found * Server nginx is not blacklisted < Server: nginx < Date: Fri, 16 Feb 2018 18:59:47 GMT < Content-Type: text/html; charset=utf-8 < Content-Length: 0 < Connection: keep-alive < Cache-Control: no-cache < Content-Security-Policy: sandbox < Location: https://dl.dropboxusercontent.com/content_link/NShAQ0eUYa8BqhfP8UBRQqrucOsW2CF5PxKzXbYSx4eWxRvzBYh4E9U4Y0EVDSFc/file < Pragma: no-cache < Referrer-Policy: origin-when-cross-origin < X-Content-Type-Options: nosniff < X-Dropbox-Request-Id: 074229cb353345723b385c8068325b6b < X-Frame-Options: DENY < X-Robots-Tag: noindex, nofollow, noimageindex < X-Xss-Protection: 1; mode=block < Strict-Transport-Security: max-age=15552000; includeSubDomains < * Connection #0 to host www.dropbox.com left intact * Issue another request to this URL: 'https://dl.dropboxusercontent.com/content_link/NShAQ0eUYa8BqhfP8UBRQqrucOsW2CF5PxKzXbYSx4eWxRvzBYh4E9U4Y0EVDSFc/file' > GET /content_link/NShAQ0eUYa8BqhfP8UBRQqrucOsW2CF5PxKzXbYSx4eWxRvzBYh4E9U4Y0EVDSFc/file HTTP/1.1 > User-Agent: curl/7.33.0 > Host: dl.dropboxusercontent.com > Accept: */* > Range:bytes=0-10 > < HTTP/1.1 206 PARTIAL CONTENT * Server nginx is not blacklisted < Server: nginx < Date: Fri, 16 Feb 2018 18:59:48 GMT < Content-Type: video/quicktime < Content-Length: 11 < Connection: keep-alive < referrer-policy: no-referrer < x-robots-tag: noindex, nofollow, noimageindex < content-disposition: inline; filename="big_buck_bunny_480p_h264.mov"; filename*=UTF-8''big_buck_bunny_480p_h264.mov < accept-ranges: bytes < content-security-policy: referrer no-referrer < content-range: bytes 0-10/249229883 < etag: 376876n < x-dropbox-request-id: b44ad771d2c348375d715a4717681983 < pragma: public < cache-control: max-age=60 < x-content-security-policy: referrer no-referrer < x-webkit-csp: referrer no-referrer < Strict-Transport-Security: max-age=15552000; includeSubDomains < * Connection #1 to host dl.dropboxusercontent.com left intact ftypqt That said, if the client can't support this (e.g., with the redirect), it is technically possible to modify the links for access directly via dl.dropboxusercontent.com, e.g.: https://dl.dropboxusercontent.com/s/yo9nbii33pfwmtt/big_buck_bunny_480p_h264.mov This isn't officially supported/documented though.
So, I proto-typed my own html5-video webpage, downloaded your MOV file, and put it out onto my Google-Cloud-Platform, and that works fine (in Chrome on Win-10). So, then I changed only the 'src=...' attribute on the source-tag to point out to your file on Dropbox. I ran two test cases, one with the trailing "&raw=1" and one without. Both fail...in the debug-console, I get a media "ERROR 4'...specifically: MEDIA_ERR_SRC_NOT_SUPPORTED) The media could not be loaded, either because the server or network failed or because the format is not supported." (Hmmm...I'm not sure what to conclude, but for what it's worth, I too use video.js, just like I've been doing for about a year now.) But this makes me want to recommend you consider giving Google Cloud Platform a whirl, if you're not wedded to wanting to use Dropbox. EDIT/UPDATE: As I stated in my newest comment below, once I re-tested, using the alternate URL of https://dl.dropboxusercontent.com/s/yo9nbii33pfwmtt/big_buck_bunny_480p_h264.mov my code now DOES work correctly...no more media-errors. Sorry for any earlier confustion.
Express JS 4.0, serve binary data, request Accept header changes output
Thanks in advance.
Short:
Express JS 4.0 alters the output data, due to the Accept headers in the request.
Is there a way for me to override this behaviour, and just write the same data regardless of the request headers.
When Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8 is present output is changed.
Is there a way I can ignore, remove, override these headers.
Long (probably tl;dr):
I am trying to serve binary data from a Node/ExpressJS app.
I am storing a compressed log file (plain/text), that has been gzipped, base64 encoded and sent to my server app, where it is being stored in a mongo database using mongoose. I know this is probably not optimal, but is currently a necessary evil. This is working fine.
$(gzip --stdout /var/log/cloud-init-script.log | base64 --wrap=0)
Is being used to compress and base64 the data, before it is sent with other data as part of a json post.
The problem occurs when I attempt to retrieve, decode the base64 encoded string and send to the browser as a binary gzip file.
// node, referring to the machine the log came from
var log = new Buffer(node.log, 'base64');
res.setHeader('Content-Disposition', 'attachment; filename=' + node.name + "-log.gz");
res.setHeader('Content-Type', 'application/x-gzip');
res.setHeader('Content-Length', log.length);
console.log(log.toString('hex'));
// res.end(log, 'binary'); I tried this hoping I could by pass, some content-negotiation
res.send(log);
I had this working when using ExpressJS 3.0 using res.send.
But when I updated to ExpressJS 4.0 the downloaded data, ceased to extract properly. The data being pulled down seemingly corrupt somehow.
I started to try and fix this by comparing the downloaded file and the source file in hexidecimal output using xxd or od and found that the downloaded file was different to the source. I also dumped the hex of the NodeJS Buffer just before it is sent to the client to console, and this matches the source.
I have been banging my head against this issued for nearly a day now, and have suspected that NodeJS might be doing something funky with character encoding (UTF-8 v. Buffer v. UTF16 Strings), OS endianess.
Eventually finding none of this the be problem, I had assumed NodeJS had always been outputting the wrong data to the browser, which was correct, but it wasn't "Always" outputting the wrong data.
I had a break through, when I did a curl request to the endpoint, and the data came through as expected (matching the source), I then added the request headers that were sent with my browser requests, and got back the mangled data.
Actual log file:
I'm a log file
Good Request:
> User-Agent: curl/7.37.1
> Host: 127.0.0.1:9000
> Accept: */*
>
< HTTP/1.1 200 OK
< X-Powered-By: Express
< Last-Modified: Tue, 26 May 2015 11:47:46 GMT
< Content-Description: File Transfer
< Content-Disposition: attachment; filename=test-log.gz
< Content-Type: application/x-gzip
< Content-Transfer-Encoding: binary
< Content-Length: 57
< Date: Tue, 26 May 2015 11:47:46 GMT
< Connection: keep-alive
0000000: 1f8b 0808 0256 6455 0003 636c 6f75 642d .....VdU..cloud-
0000010: 696e 6974 2d73 6372 6970 742e 6c6f 6700 init-script.log.
0000020: f354 cf55 4854 c8c9 4f57 48cb cc49 e502 .T.UHT..OWH..I..
0000030: 003b 5ff5 5f0f 0000 00 .;_._....
Bad Request:
> Host: localhost:9000
> Connection: keep-alive
> Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8
> User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_3) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/43.0.2357.65 Safari/537.36
> Referer: http://localhost:9000/nodes?query=environment%3D5549b6cbdc023b5e26fe6bd4%20type%3Dnat
> Accept-Language: en-US,en;q=0.8
>
< HTTP/1.1 200 OK
< X-Powered-By: Express
< Last-Modified: Tue, 26 May 2015 11:47:00 GMT
< Content-Description: File Transfer
< Content-Disposition: attachment; filename=test-log.gz
< Content-Type: application/x-gzip
< Content-Transfer-Encoding: binary
< content-length: 57
< Date: Tue, 26 May 2015 11:47:00 GMT
< Connection: keep-alive
0000000: 1ffd 0808 0256 6455 0003 636c 6f75 642d .....VdU..cloud-
0000010: 696e 6974 2d73 6372 6970 742e 6c6f 6700 init-script.log.
0000020: fd54 fd55 4854 fdfd 4f57 48fd fd49 fd02 .T.UHT..OWH..I..
0000030: 003b 5ffd 5f0f 0000 00 .;_._....
res.end(node.log, 'base64'); instead of res.send(log); Where node.log is the raw base64 encoded String and log was a Buffer that had decoded that string. Bearing in mind I am using Node v0.10.38. I ended up following the function call chain. // I call res.send(log); // ExpressJS calls on http.ServerResponse this.end(chunk, encoding); // chunk = Buffer, encoding = undefined // NodeJS http.ServerResponse calls res.inject(string); At this point NodeJS appears to be treating the data as a string, which is where the buffer contents were being mangled. This behaviour was different when the 'Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8' header was not present, a different end(chunk, encoding) function was being called in this case, not using res.inject and not mangling the Buffer data. I am not entirely sure where the content negotiation is happening and what is swapping in the different res.end functions, whether this is NodeJS or ExpressJS, but it would be nice to be able to control this content negotiation in some simple way.
Ajax GET request of URL fails, but hurl.it GET request of same URL works. What gives?
I'm trying to access the contents of a web page as part of the functionality of a javascript Chrome extension I'm creating and have encountered a bit of a puzzle.
When accessing the resource as part of an Ajax GET request in my extension's script, the resource does not correctly load. When I attempt the same GET request through hurl.it (with follow-redirects on and no header modifications), the data loads. It also works if I just enter the URL in my browser.
I can't figure out what hurl.it is doing differently in its request and how to fix my own.
The URL I'm trying to query is in the form of (with 'Hello' as an example search):
http://overdrive.dclibrary.org/BANGSearch.dll?Type=FullText&PerPage=24&URL=SearchResults.htm&Sort=SortBy%3DRelevancy&FullTextField=All&FullTextCriteria=Hello&x=0&y=0%22
This would appear in my script like:
var get_url = "http://overdrive.dclibrary.org/BANGSearch.dll?Type=FullText&PerPage=24&URL=SearchResults.htm&Sort=SortBy%3DRelevancy&FullTextField=All&FullTextCriteria=Hello&x=0&y=0"
$.get(get_url,function(data){
console.log(data);
});
To be clear, the above code will output HTML to the console. It just doesn't include any of the results from the search query.
Thanks in advance!
Edit: My extension has been given permission to access anything in the dclibrary.org domain.
There's a redirect in the response, which can break a browser. HTTP/1.1 302 Moved Temporarily works in chrome though. why is it returning a 302 response? With ASP.net/IIS sometimes unauthorized (not logged in) users are redirected with a 302 response. This is bad behavior, if login is needed, it should issue a 403, but obviously this is not the intent.
Use Fiddler to debug full headers (or chrome dev tools).
HTTP/1.1 302 Moved Temporarily
Cache-Control: private
Content-Type: text/html; charset=utf-8
Location: http://overdrive.dclibrary.org/4F2C56FC-9659-4640-9E00-9433B3CC9A7F/10/50/en/SearchResults.htm?searchid=38432201s&sortby=Relevancy
Server: Microsoft-IIS/7.0
X-AspNetMvc-Version: 4.0
X-AspNet-Version: 4.0.30319
Set-Cookie: Session=4F2C56FC-9659-4640-9E00-9433B3CC9A7F|0|0|50|en; expires=Tue, 01-Jan-2030 00:00:00 GMT; path=/; HttpOnly
X-Powered-By: ASP.NET
Date: Fri, 06 Mar 2015 20:53:31 GMT
Content-Length: 12484
Connection: keep-alive
Keep-Alive: 60
Via: HTTP/1.1 proxy2444
<html><head><script type="text/javascript">window.NREUM||(NREUM={});NREUM.info = {"beacon":"bam.nr-data.net","errorBeacon":"bam.nr-data.net","licenseKey":"ad9513338b","applicationID":"2495152,2495041","transactionName":"MVBbNkcACBADUU1QWggafQ1BLwMXIV1XTUcJWVUHR04kAgxVaVhSAxpwDFEEHg==","queueTime":0,"applicationTime":61,"ttGuid":"1260BAD900521DF4","agent":"js-agent.newrelic.com/nr-593.min.js"}</script><script type="text/javascript">(window.NREUM||(NREUM={})).loader_config={xpid:"VwIAVVRbGwEEXVRTAgM="};window.NREUM||(NREUM={}),__nr_require=function(t,e,n){function r(n){if(!e[n]){var o=e[n]={exports:{}};t[n][0].call(o.exports,function(e){var o=t[n][1][e];return r(o?o:e)},o,o.exports)}return e[n].exports}if("function"==typeof __nr_require)return __nr_require;for(var o=0;o<n.length;o++)r(n[o]);return r}({QJf3ax:[function(t,e){function n(t){function e(e,n,a){t&&t(e,n,a),a||(a={});for(var c=s(e),f=c.length,u=i(a,o,r),d=0;f>d;d++)c[d].apply(u,n);return u}function a(t,e){f[t]=s(t).concat(e)}function s(t){return f[t]||[]}function c(){return n(e)}var f={};return{on:a,emit:e,create:c,listeners:s,_events:f}}function r(){return{}}var o="nr#context",i=t("gos");e.exports=n()},{gos:"7eSDFh"}],ee:[function(t,e){e.exports=t("QJf3ax")},{}],3:[function(t){function e(t){try{i.console&&console.log(t)}catch(e){}}var n,r=t("ee"),o=t(1),i={};try{n=localStorage.getItem("__nr_flags").split(","),console&&"function"==typeof console.log&&(i.console=!0,-1!==n.indexOf("dev")&&(i.dev=!0),-1!==n.indexOf("nr_dev")&&(i.nrDev=!0))}catch(a){}i.nrDev&&r.on("internal-error",function(t){e(t.stack)}),i.dev&&r.on("fn-err",function(t,n,r){e(r.stack)}),i.dev&&(e("NR AGENT IN DEVELOPMENT MODE"),e("flags: "+o(i,function(t){return t}).join(", ")))},{1:20,ee:"QJf3ax"}],4:[function(t){function e(t,e,n,i,s){try{c?c-=1:r("err",[s||new UncaughtException(t,e,n)])}catch(f){try{r("ierr",[f,(new Date).getTime(),!0])}catch(u){}}return"function"==typeof a?a.apply(this,o(arguments)):!1}function UncaughtException(t,e,n){this.message=t||"Uncaught error with no additional information",this.sourceURL=e,this.line=n}function n(t){r("err",[t,(new Date).getTime()])}var r=t("handle"),o=t(6),i=t("ee"),a=window.onerror,s=!1,c=0;t("loader").features.err=!0,t(3),window.onerror=e;try{throw new Error}catch(f){"stack"in f&&(t(4),t(5),"addEventListener"in window&&t(1),window.XMLHttpRequest&&XMLHttpRequest.prototype&&XMLHttpRequest.prototype.addEventListener&&t(2),s=!0)}i.on("fn-start",function(){s&&(c+=1)}),i.on("fn-err",function(t,e,r){s&&(this.thrown=!0,n(r))}),i.on("fn-end",function(){s&&!this.thrown&&c>0&&(c-=1)}),i.on("internal-error",function(t){r("ierr",[t,(new Date).getTime(),!0])})},{1:5,2:8,3:3,4:7,5:6,6:21,ee:"QJf3ax",handle:"D5DuLP",loader:"G9z0Bl"}],5:[function(t,e){function n(t){i.inPlace(t,["addEventListener","removeEventListener"],"-",r)}function r(t){return t[1]}var o=(t(1),t("ee").create()),i=t(2)(o),a=t("gos");if(e.exports=o,n(window),"getPrototypeOf"in Object){for(var s=document;s&&!s.hasOwnProperty("addEventListener");)s=Object.getPrototypeOf(s);s&&n(s);for(var c=XMLHttpRequest.prototype;c&&!c.hasOwnProperty("addEventListener");)c=Object.getPrototypeOf(c);c&&n(c)}else XMLHttpRequest.prototype.hasOwnProperty("addEventListener")&&n(XMLHttpRequest.prototype);o.on("addEventListener-start",function(t){if(t[1]){var e=t[1];"function"==typeof e?this.wrapped=t[1]=a(e,"nr#wrapped",function(){return i(e,"fn-",null,e.name||"anonymous")}):"function"==typeof e.handleEvent&&i.inPlace(e,["handleEvent"],"fn-")}}),o.on("removeEventListener-start",function(t){var e=this.wrapped;e&&(t[1]=e)})},{1:21,2:22,ee:"QJf3ax",gos:"7eSDFh"}],6:[function(t,e){var n=(t(2),t("ee").create()),r=t(1)(n);e.exports=n,r.inPlace(window,["requestAnimationFrame","mozRequestAnimationFrame","webkitRequestAnimationFrame","msRequestAnimationFrame"],"raf-"),n.on("raf-start",function(t){t[0]=r(t[0],"fn-")})},{1:22,2:21,ee:"QJf3ax"}],7:[function(t,e){function n(t,e,n){var r=t[0];"string"==typeof r&&(r=new Function(r)),t[0]=o(r,"fn-",null,n)}var r=(t(2),t("ee").create()),o=t(1)(r);e.exports=r,o.inPlace(window,["setTimeout","setInterval","setImmediate"],"setTimer-"),r.on("setTimer-start",n)},{1:22,2:21,ee:"QJf3ax"}],8:[function(t,e){function n(){f.inPlace(this,p,"fn-")}function r(t,e){f.inPlace(e,["onreadystatechange"],"fn-")}function o(t,e){return e}function i(t,e){for(var n in t)e[n]=t[n];return e}var a=t("ee").create(),s=t(1),c=t(2),f=c(a),u=c(s),d=window.XMLHttpRequest,p=["onload","onerror","onabort","onloadstart","onloadend","onprogress","ontimeout"];e.exports=a,window.XMLHttpRequest=function(t){var e=new d(t);try{a.emit("new-xhr",[],e),u.inPlace(e,["addEventListener","removeEventListener"],"-",function(t,e){return e}),e.addEventListener("readystatechange",n,!1)}catch(r){try{a.emit("internal-error",[r])}catch(o){}}return e},i(d,XMLHttpRequest),XMLHttpRequest.prototype=d.prototype,f.inPlace(XMLHttpRequest.prototype,["open","send"],"-xhr-",o),a.on("send-xhr-start",r),a.on("open-xhr-start",r)},{1:5,2:22,ee:"QJf3ax"}],9:[function(t){function e(t){if("string"==typeof t&&t.length)return t.length;if("object"!=typeof t)return void 0;if("undefined"!=typeof ArrayBuffer&&t instanceof ArrayBuffer&&t.byteLength)return t.byteLength;if("undefined"!=typeof Blob&&t instanceof Blob&&t.size)return t.size;if("undefined"!=typeof FormData&&t instanceof FormData)return void 0;try{return JSON.stringify(t).length}catch(e){return void 0}}function n(t){var n=this.params,r=this.metrics;if(!this.ended){this.ended=!0;for(var i=0;c>i;i++)t.removeEventListener(s[i],this.listener,!1);if(!n.aborted){if(r.duration=(new Date).getTime()-this.startTime,4===t.readyState){n.status=t.status;var a=t.responseType,f="arraybuffer"===a||"blob"===a||"json"===a?t.response:t.responseText,u=e(f);if(u&&(r.rxSize=u),this.sameOrigin){var d=t.getResponseHeader("X-NewRelic-App-Data");d&&(n.cat=d.split(", ").pop())}}else n.status=0;r.cbTime=this.cbTime,o("xhr",[n,r,this.startTime])}}}function r(t,e){var n=i(e),r=t.params;r.host=n.hostname+":"+n.port,r.pathname=n.pathname,t.sameOrigin=n.sameOrigin}if(window.XMLHttpRequest&&XMLHttpRequest.prototype&&XMLHttpRequest.prototype.addEventListener&&!/CriOS/.test(navigator.userAgent)){t("loader").features.xhr=!0;var o=t("handle"),i=t(2),a=t("ee"),s=["load","error","abort","timeout"],c=s.length,f=t(1);t(4),t(3),a.on("new-xhr",function(){this.totalCbs=0,this.called=0,this.cbTime=0,this.end=n,this.ended=!1,this.xhrGuids={}}),a.on("open-xhr-start",function(t){this.params={method:t[0]},r(this,t[1]),this.metrics={}}),a.on("open-xhr-end",function(t,e){"loader_config"in NREUM&&"xpid"in NREUM.loader_config&&this.sameOrigin&&e.setRequestHeader("X-NewRelic-ID",NREUM.loader_config.xpid)}),a.on("send-xhr-start",function(t,n){var r=this.metrics,o=t[0],i=this;if(r&&o){var f=e(o);f&&(r.txSize=f)}this.startTime=(new Date).getTime(),this.listener=function(t){try{"abort"===t.type&&(i.params.aborted=!0),("load"!==t.type||i.called===i.totalCbs&&(i.onloadCalled||"function"!=typeof n.onload))&&i.end(n)}catch(e){try{a.emit("internal-error",[e])}catch(r){}}};for(var u=0;c>u;u++)n.addEventListener(s[u],this.listener,!1)}),a.on("xhr-cb-time",function(t,e,n){this.cbTime+=t,e?this.onloadCalled=!0:this.called+=1,this.called!==this.totalCbs||!this.onloadCalled&&"function"==typeof n.onload||this.end(n)}),a.on("xhr-load-added",function(t,e){var n=""+f(t)+!!e;this.xhrGuids&&!this.xhrGuids[n]&&(this.xhrGuids[n]=!0,this.totalCbs+=1)}),a.on("xhr-load-removed",function(t,e){var n=""+f(t)+!!e;this.xhrGuids&&this.xhrGuids[n]&&(delete this.xhrGuids[n],this.totalCbs-=1)}),a.on("addEventListener-end",function(t,e){e instanceof XMLHttpRequest&&"load"===t[0]&&a.emit("xhr-load-added",[t[1],t[2]],e)}),a.on("removeEventListener-end",function(t,e){e instanceof XMLHttpRequest&&"load"===t[0]&&a.emit("xhr-load-removed",[t[1],t[2]],e)}),a.on("fn-start",function(t,e,n){e instanceof XMLHttpRequest&&("onload"===n&&(this.onload=!0),("load"===(t[0]&&t[0].type)||this.onload)&&(this.xhrCbStart=(new Date).getTime()))}),a.on("fn-end",function(t,e){this.xhrCbStart&&a.emit("xhr-cb-time",[(new Date).getTime()-this.xhrCbStart,this.onload,e],e)})}},{1:"XL7HBI",2:10,3:8,4:5,ee:"QJf3ax",handle:"D5DuLP",loader:"G9z0Bl"}],10:[function(t,e){e.exports=function(t){var e=document.createElement("a"),n=window.location,r={};e.href=t,r.port=e.port;var o=e.href.split("://");return!r.port&&o[1]&&(r.port=o[1].split("/")[0].split("#").pop().split(":")[1]),r.port&&"0"!==r.port||(r.port="https"===o[0]?"443":"80"),r.hostname=e.hostname||n.hostname,r.pathname=e.pathname,r.protocol=o[0],"/"!==r.pathname.charAt(0)&&(r.pathname="/"+r.pathname),r.sameOrigin=!e.hostname||e.hostname===document.domain&&e.port===n.port&&e.protocol===n.protocol,r}},{}],11:[function(t,e){function n(t){return function(){r(t,[(new Date).getTime()].concat(i(arguments)))}}var r=t("handle"),o=t(1),i=t(2);"undefined"==typeof window.newrelic&&(newrelic=window.NREUM);var a=["setPageViewName","addPageAction","setCustomAttribute","finished","addToTrace","inlineHit","noticeError"];o(a,function(t,e){window.NREUM[e]=n("api-"+e)}),e.exports=window.NREUM},{1:20,2:21,handle:"D5DuLP"}],gos:[function(t,e){e.exports=t("7eSDFh")},{}],"7eSDFh":[function(t,e){function n(t,e,n){if(r.call(t,e))return t[e];var o=n();if(Object.defineProperty&&Object.keys)try{return Object.defineProperty(t,e,{value:o,writable:!0,enumerable:!1}),o}catch(i){}return t[e]=o,o}var r=Object.prototype.hasOwnProperty;e.exports=n},{}],D5DuLP:[function(t,e){function n(t,e,n){return r.listeners(t).length?r.emit(t,e,n):(o[t]||(o[t]=[]),void o[t].push(e))}var r=t("ee").create(),o={};e.exports=n,n.ee=r,r.q=o},{ee:"QJf3ax"}],handle:[function(t,e){e.exports=t("D5DuLP")},{}],XL7HBI:[function(t,e){function n(t){var e=typeof t;return!t||"object"!==e&&"function"!==e?-1:t===window?0:i(t,o,function(){return r++})}var r=1,o="nr#id",i=t("gos");e.exports=n},{gos:"7eSDFh"}],id:[function(t,e){e.exports=t("XL7HBI")},{}],loader:[function(t,e){e.exports=t("G9z0Bl")},{}],G9z0Bl:[function(t,e){function n(){var t=l.info=NREUM.info;if(t&&t.licenseKey&&t.applicationID&&f&&f.body){s(h,function(e,n){e in t||(t[e]=n)}),l.proto="https"===p.split(":")[0]||t.sslForHttp?"https://":"http://",a("mark",["onload",i()]);var e=f.createElement("script");e.src=l.proto+t.agent,f.body.appendChild(e)}}function r(){"complete"===f.readyState&&o()}function o(){a("mark",["domContent",i()])}function i(){return(new Date).getTime()}var a=t("handle"),s=t(1),c=(t(2),window),f=c.document,u="addEventListener",d="attachEvent",p=(""+location).split("?")[0],h={beacon:"bam.nr-data.net",errorBeacon:"bam.nr-data.net",agent:"js-agent.newrelic.com/nr-593.min.js"},l=e.exports={offset:i(),origin:p,features:{}};f[u]?(f[u]("DOMContentLoaded",o,!1),c[u]("load",n,!1)):(f[d]("onreadystatechange",r),c[d]("onload",n)),a("mark",["firstbyte",i()])},{1:20,2:11,handle:"D5DuLP"}],20:[function(t,e){function n(t,e){var n=[],o="",i=0;for(o in t)r.call(t,o)&&(n[i]=e(o,t[o]),i+=1);return n}var r=Object.prototype.hasOwnProperty;e.exports=n},{}],21:[function(t,e){function n(t,e,n){e||(e=0),"undefined"==typeof n&&(n=t?t.length:0);for(var r=-1,o=n-e||0,i=Array(0>o?0:o);++r<o;)i[r]=t[e+r];return i}e.exports=n},{}],22:[function(t,e){function n(t){return!(t&&"function"==typeof t&&t.apply&&!t[i])}var r=t("ee"),o=t(1),i="nr#wrapper",a=Object.prototype.hasOwnProperty;e.exports=function(t){function e(t,e,r,a){function nrWrapper(){var n,i,s,f;try{i=this,n=o(arguments),s=r&&r(n,i)||{}}catch(d){u([d,"",[n,i,a],s])}c(e+"start",[n,i,a],s);try{return f=t.apply(i,n)}catch(p){throw c(e+"err",[n,i,p],s),p}finally{c(e+"end",[n,i,f],s)}}return n(t)?t:(e||(e=""),nrWrapper[i]=!0,f(t,nrWrapper),nrWrapper)}function s(t,r,o,i){o||(o="");var a,s,c,f="-"===o.charAt(0);for(c=0;c<r.length;c++)s=r[c],a=t[s],n(a)||(t[s]=e(a,f?s+o:o,i,s,t))}function c(e,n,r){try{t.emit(e,n,r)}catch(o){u([o,e,n,r])}}function f(t,e){if(Object.defineProperty&&Object.keys)try{var n=Object.keys(t);return n.forEach(function(n){Object.defineProperty(e,n,{get:function(){return t[n]},set:function(e){return t[n]=e,e}})}),e}catch(r){u([r])}for(var o in t)a.call(t,o)&&(e[o]=t[o]);return e}function u(e){try{t.emit("internal-error",e)}catch(n){}}return t||(t=r),e.inPlace=s,e.flag=i,e}},{1:21,ee:"QJf3ax"}]},{},["G9z0Bl",4,9]);</script><title>Object moved</title></head><body>
<h2>Object moved to here.</h2>
</body></html>
Strange behavior (ajax long-polling channel) "refuses" connection from normal browser?
When you copy this link http://q55.queue.vkontakte.ru/im639 and place it to currect browser tab, press enter, it does "load", address changes, but content is still the same (you're still in this question). What's that? Is that programmatical behavior ?
I am not seeing anything. It does not do anything because nothing is available. alfred#alfred-laptop:~/node/contact$ curl -v http://q55.queue.vkontakte.ru/im639* About to connect() to q55.queue.vkontakte.ru port 80 (#0) * Trying 87.240.134.232... connected * Connected to q55.queue.vkontakte.ru (87.240.134.232) port 80 (#0) > GET /im639 HTTP/1.1 > User-Agent: curl/7.21.0 (i686-pc-linux-gnu) libcurl/7.21.0 OpenSSL/0.9.8o zlib/1.2.3.4 libidn/1.18 > Host: q55.queue.vkontakte.ru > Accept: */* > < HTTP/1.1 204 No Content < Server: nginx/0.7.59 < Date: Mon, 11 Jul 2011 18:49:25 GMT < Content-Type: text/html < Connection: keep-alive < * Connection #0 to host q55.queue.vkontakte.ru left intact * Closing connection #0 We get status code HTTP/1.1 204 No Content Also this has nothing to do with long-polling, because the connection is not hanging at all. It looks like the URL is pointing to an image. I can not image you should be doing long-polling for retrieving a simple image.
The server responds with a 204. See here which explains that on a 204 server response: If the client is a user agent, it SHOULD NOT change its document view from that which caused the request to be sent.