For Adobe Analytics tracking HTTP response header (sorry I can't paste my request here for privacy), I can see the following
Content-Length:43
Content-Type:image/gif
I am not sure why Adobe Analytics returns 43 size tracking pixel rather than smaller one. Does Adobe Analytics client-side javascript need to read this Content-Length header for any verification?
What if I return HTTP 204 no content, will that also work?
the pixel is really only there because of legacy systems and old browser support.
experience cloud & moving to AAM will change the response to a javascript JSON object
43 bytes is pretty tiny, I wouldn't worry about 43 bytes. 2x2 pixel dimension really means nothing.
a 204 response is normal, unless you have AAM
Related
I'm using postman to test a continous webm videostream. But the range request is being ignored.
If I try using an image in the same server, range works ok. If I try it on as fixed length video it works ok.
This link has the fixed webm video I tested and worked: https://github.com/rubu/WebMPlayer/blob/master/Samples/big_buck_bunny_live.webm?raw=true
I can't provide the specific continuous stream I'm using because it's a corporative asset. Nor I was able to find any webm streams live on the web
Anyone knows how I can make range work for streams ? If someone knows any continuous webm stream that we could use as a test here it would also be helpful.
What I want is to generate a request that I can use in JMeter to include in a load test. So if someone can demonstrate how to do this request that loads a small amount of a continuous web stream in JMeter the answer is valid too.
You can see that accepting ranges is a server-side configuration as explained here
You'll see that in a less public server (than GitHub) you will be able to send a GET request and receive a Accept-Ranges: bytes so it depends on the configuration.
My working example is illustrated here :
NB : As stated in RFC7233's Intro this is only possible with GET requests.
I'm using the "get an upload session, upload chunks" method. Generally, it's working. I'm using a chunk size of 640 * 1024, which according to the docs is legit.
Occasionally I'll get a response code of 416 (Requested Range Not Satisfiable). The Upload large files with an upload session documentation is not very clear on what to do when I get one:
On failures when the client sent a fragment the server had already received, the server will respond with HTTP 416 Requested Range Not Satisfiable.
I am keeping track in my code of the chunks, which I believe I am doing correctly. Is there another reason I might get a 416? I will say that I was getting crappy upload speeds from my ISP at this time.
If I do get a 416, should I just retry it? Or should I ignore it, and believe the docs, that (for some reason) that chunk has already been received?
I am calling the Microsoft Graph REST API from Node.js (JavaScript). I receive the result of GET operations for a single cell which is empty as returned with a status code 429 "TooManyRequests - The server is busy. Please try again later." error. Another SO question [ Microsoft Graph throttling Excel updates ] has answers that point to MS documentation about making smaller requests. Unfortunately, the suggestions are rather vague.
My question is does the size of the file in OneDrive have an impact on throttling? The file I am attempting to update is over 4 MB in size. However, the updates (PATCH) that I have attempted are only 251 bytes (12 cells) and I continue to get the error. Even a GET for a single cell receives this. This happened after 72 hours of inactivity. I am using a business account, and unfortunately MS support will not help, as they will only speak to Admins.
Assuming this is an unrelated issue, as I do have about 3500 rows (of about 12 columns) to update, what is the best "chunk size" to update them in? Is 50 ok? Is 100 ok? Thank You!
NOTE: This same throttling happens in the Graph Explorer, not just via code. Also, there is no Retry-After field returned in the Response Headers.
From what have gathered so far, Apple provided tools to make Mac to act as HTTP Live Streaming server. But my goal is different. I want to make iDevices to be the HTTP Live Streaming server. (for local network only)
Can it be done at all?
Yes and no. Apple does not provide a way to stream encoded media data, so that part is 100% up to you. Also, Apple does not provide a way to access encoded frames directly (i.e. you can easily get an encoded file or the raw frames, but not easily get "encoded frames'). So you need to develop a way to get these encoded frames from the files for streaming, or encode the raw frames on the fly.
It may or may not fit your use case, but if you first right the streamer portion, you should be able to say small/short clips to disk, and stream them out as they are created with minimal overall latency.
Is it possible to encrypt/decrypt smaller segments of a file for HTTP Live Streaming, with industry-standard encryption techniques such as PlayReady and AES-128?
I don't know how the default HLS implementation in iOS works with AES-128 encryption - i.e, is it still able to download partial segments (TS) and stream files progressively? Or does it have to download the full file, decrypt the entire contents and only then start playback?
In some PlayReady clients I've been exposed to, I've observed the latter approach (download in full first). But it seems like an awful compromise on playback latency, to attain security (and perhaps there is no way around it).
Some light on this subject would be very helpful. Thanks!
P.S: References to technical documentation or manuals would be great!
AES works a block cipher with a block size of 128 bits. So if the decryption program knows the key and the IV, it can return plaintext from the first block -- there's no reason to decrypt an entire segment/fragment first.
I'm guessing the PlayReady implementations you see are only doing it on a file basis because that is slightly easier to implement. But there's no technical reason that a client would need to retrieve the entire file before initiating the decryption.
You can verify what a client is doing by making a fragment/segment extremely large and checking client behavior.
A quick search found me this project which is decrypting HLS as it reads:
https://code.google.com/p/mlbtv-hls-nexdef/source/browse/trunk/mlb.c