I would like to represent dynamic images in an email. For example with the given url
<img src="http://myserver.com/index.php/user_key/thispagestate.jpg" />
I would like to serve a different image based on logic within my server. There will only be between 2 to 4 static images used to represent the result of any given request.
The 2 options I had in mind were:
to serve the images directly using perhaps
imagecreatefromjpeg
Or generate 302 redirects
Seeing as each request will result in one of a limited number of images I thought a redirect might save resources on our end and make use of caching on the user's end too. The result for each request will change depending on the user and time, perhaps using redirects will have some consecuence for SEO or spam filtering?
Your opinions on the best method will be appreciated
The 2 options I had in mind were:
to serve the images directly using
perhaps imagecreatefromjpeg Or
generate 302 redirects
I'd go with #1 in this case, though since it's a static image you can simply use:
header("Cache-Control: no-cache, must-revalidate"); // HTTP/1.1
header("Expires: Sat, 26 Jul 1997 05:00:00 GMT"); // Date in the past
header('Content-Type: image/jpg'); // or image/png, etc.
echo file_get_contents($image_path); // where $image_path is the path to the image
exit;
instead. You'd only need to use the GD functions if you're were trying to do something like adding text on top of the static image.
Note in this cache I'm setting it to cache expire, since the URL will be the same, but the content might change. This could potentially confuse caching systems.
Seeing as each request will result in
one of a limited number of images I
thought a redirect might save
resources on our end and make use of
caching on the user's end too.
The reverse actually, since the same file will now have different content. You'll want them to revalidate the content each time to make sure the proper image shows.
Related
Is it possible to use Kdb+ http client to access pages protected by login? I am using https://github.com/KxSystems/cookbook/blob/master/yahoo.q as example of basic GET/POST. Does anyone have an example how to extract a cookie and use it in the following requests?
It is probably a bit crude, but the following will extract headers from an http, then cookies, parse and return as a dictionary:
x:"HTTP/1.0 200 OK\r\nContent-type: text/html\r\nSet-Cookie: theme=light\r\nSet-Cookie: sessionToken=abc123; Expires=Wed, 09 Jun 2021 10:18:14 GMT\r\n\r\n";
left:{(first y ss x)#y};
vs1:{{(y#x;(count[z]+y)_x)}[y;;x](first y ss x)};
headers:{{(`$x[0];x[1])} flip vs1[": "] each 1_"\r\n" vs left["\r\n\r\n"]x};
cookies:{(!). {(`$x[0];x[1])} flip vs1["="] each {x[1]#where x[0]=`$"Set-Cookie"} x};
cookies headers[x]
Whilst you might be able to various bits and bobs from an http response, the fact that you won't be able to manipulate http methods means that q can't be your tool to do this - well, not without some vigorous effort.
I would use something like Beautiful Soup in conjunction with q. Soup has some great tools for handling this kind of thing (e.g. cookies etc). There are various other similar projects too.
System call for Beautiful Soup that make relevant get/post/put calls and download required data
system"/path/to/code.py"
Where the code dumps the result somewhere or puts it into kdb directly. Then do whatever you like with it.
OK, here's a goal I've been looking for a while.
As it's known, most advertising and analytics companies use a so called "pixel" code in order to track websites views, transactions, conversion etc.
I do have a general idea on how it works, the problem is how to implement it. The tracking codes consist from few parts.
The tracking code itself.
This is the code that the users inserts on his webpage in the <head> section. The main goal of this code is to set some customer specific variables and to call the *.js file.
*.js file.
This file holds all the magic of CRUD (create/read/update/delete) cookies, track user's events and interaction with the webpage.
The pixel code.
This is an <img> tag with the src atribute pointing to an image *.gif (for example) file that takes all the parameters collected on the page, and stores them in the database.
Example:
WordPress pixel code: <img id="wpstats" src="http://stats.wordpress.com/g.gif?host=www.hostname.com&list_of_cookies_value_pairs;" alt="">
Google Analitycs:
http://www.google-analytics.com/__utm.gif?utmwv=4&utmn=769876874&etc
Now, it's obvious that the *.gif request has to reach a server side scripting language in order to read the parameters data and store them in a db.
Does anyone have an idea how to implement this in Zend?
UPDATE
Another thing I'm interested in is: How to avoid the user's browser to load the cached *.gif ? Will a random parameter value do the trick? Example: src="pixel.gif?nocache=random_number" where the nocache parameter value will be different on every request.
As Zend is built using PHP, it might be worth reading the following question and answer: Developing a tracking pixel.
In addition to this answer and as you're looking for a way of avoiding caching the tracking image, the easiest way of doing this is to append a unique/random string to it, which is generated at runtime.
For example, server-side and with the creation of each image, you might add a random URL id:
<?php
// Generate random id of min/max length
$rand_id = rand(8, 8);
// Echo the image and append a random string
echo "<img src='pixel.php?a=".$vara."&b=".$varb."&rand=".$rand_id."'>";
?>
Just adding my 2 cents to this thread because I think an important, and frequently used, option is missing: you don't necessarily need a scripting language to capture the request. A more efficient approach is to use the web server access log (like apache access log for instance) to log the request and then handle that log with whatever tools you see fit, like ELK stack for instance.
This makes serving the requests much lighter because no scripting language is loaded to prepare the response, just native apache response, which is typically much more efficient.
First of all, the *.gif doesn't need to be that file type, the only thing that is of interest is the Content-Type http header. Set that to image/gif (or any other, appropiate type) in the beginning, execute your code and render some sort of image to the response body.
Well, all of the above codes are correct and is good but to be certain, the guy above mention "g.gif"
You can just add a simple php code to write to an sql or fwrite("file.txt",$opened)
where var $opened serves as the counter++ if someone opened your mail... then save it as "g.gif"
TO DO all of this just add these:
<Files "/thisdirectory">
AddType application/x-httpd-php .gif
</Files>
to your ".htaccess" file but be sure to make a new directory for that g.gif or whatever.gif where the directory only contains g.gif and .htaccess
How should a random number generator properly be implemented in REST?
GET RANDOM/
or..
POST RANDOM/
The server returns a different random number each time.
I can see arguments for both ways.
I'd say this is the same as for a page returned that contains the current time - and many of these are done using GET. Abstractly, fetching a random number (or time) the server's state doesn't change - both time and random numbers can be described as an observation of an external event. E.g. http://random.org use atmospheric noise.
GET seems most appropriate, although caching will need to be disabled via appropriate headers, e.g.
Expires: <Current Time>
Last-Modified: <Current Time>
Cache-Control: no-cache, must-revalidate
Pragma: no-cache
If you want to ensure that the served content is already expired:
To mark a response as "already
expired," an origin server sends an
Expires date that is equal to the Date
header value. (See the rules for
expiration calculations in section
13.2.4.)
http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html
Definitely GET. Even though it might modify server-side state (if it uses a pseudo-RNG), that's just an implementation detail the client shouldn't care about.
definition of REST-call with GET: the result have to be the same -> not GET.
definition of REST-call with PUT: the result of the call can be repeatable, the server should not have problem with it -> use PUT
POST is the weakest method and can used if other are not useful.
Why not GET: the result of GET-call can be cachet (cache-header, etag oder transparent proxies) and you dont will get random results ...
Am I breaking any laws in the REST bible by returning application/octet-stream for my responses ? The REST endpoint receives 5 image urls.
{ "image1": "http://ww.o.com/1.gif",
"image2": "http://www.foo.be/2.gif" }
and it will download these and return them as application/octet-stream.
CLARIFICATION: The client that invokes this REST interface is a mobile app. Every additional network connections made will reduce battery life by a few milliamps. I am forced to use REST because it is a company standard. If not, I will do my own binary protocol.
It is not so good, as the client will not know what to do with such binary data except of storing those bytes somewhere or sending them further to some other process (if this is all you need to do with your data, then it is fine).
You may take a look at multipart content types. IMO, a multipart message containing several image/gif parts would be a better alternative.
From the sounds of this, this sounds much more like an RPC call. Specifically, "here's a list of URLs, send me back an archive".
That process is not particularly RESTful, as REST is not an RPC based system.
What you need to do is treat the archives as reources, and a way to create and then serve them up.
For example you could:
POST /archives
Content-Type: application/json
{ "image1": "http://ww.o.com/1.gif",
"image2": "http://www.foo.be/2.gif" }
As a result, you would get
HTTP/1.1 201 Created
Location: http://example.com/archives/1234
Content-Type: application/json
Then, you could make a request to http://example.com:
GET /archives/1234
Accept: multipart/mixed
Here, you will get the actual archive in a single request (like you want), only it's a multipart formatted result. (multipart/x-zip would work too, that's a zip file)
If you did:
GET /archives/1234
Accept: application/json
You would get back the JSON you sent originally (so you could, perhaps, edit and update the archive, something you may not want to support sending up the binary images).
To change it you would simply POST back the update:
PUT /archives/1234
Content-Type: application/json
{ "image1": "http://ww.o.com/1.gif",
"image2": "http://www.foo.be/2.gif",
"image3": "http://www.foo2.foo/4.gif" }
The resource is /archives/1234, that's its name.
It has two representations in this case: the JSON version, and the actual, binary archive. Your service distinguishes between the two using the content type specified in the Accept header. That header is the client telling you what it wants.
When you're done with the archive, simply DELETE it
DELETE /archives/1234
Or you can have the server expire the resource at some later time.
Why not have five separate REST calls?
Seems cleaner and divides more logically. It will also run the downloads in parallel, 2 or more at a time depending on the browser you are using.
They are called REST principles not laws, but no you are not "breaking" them, IMO. REST is about resources being addressable by a URL, and (where appropriate) available in multiple formats. It doesn't say what the format should be. There's a simple description of what REST means in this article.
However, as #Andrey says there are nicer ways to handle sending multiple data objects than inventing your own adhoc format. The Multipart mimeType / format is one alternative, and another is to send the objects packed up as a tar, zip or a similar archive file format.
IMO. the real problem with using "application/octet-stream" and is that it doesn't tell anyone anything about how the data is actually formatted. Rather your client has "know" how it is formatted, and interpret it accordingly. And the problems with inventing your own format are interoperability and (possibly) having to design, implement and maintain libraries to support it, possibly may times over.
Given:
/images: list of all images
/images/{imageId}: specific image
/feed/{feedId}: potentially huge list of some images (not all of them)
How would you query if a particular feed contains a particular image without downloading the full list? Put another way, how would you check whether a resource state contains a component without downloading the entire state? The first thought that comes to mind is:
Alias /images/{imageId} to /feed/{feedId}/images/{imageId}
Clients would then issue HTTP GET against /feed/{feedId}/images/{id} to check for its existence. The downside I see with this approach is that it forces me to hard-code logic into the client for breaking down an image URI to its proprietary id, something that REST frowns upon. Ideally I should be using the opaque image URI. Another option is:
Issue HTTP GET against /feed/{feedId}?contains={imageURI} to check for existence
but that feels a lot closer to RPC than I'd like. Any ideas?
What's wrong with this?
HEAD /images/id
It's unclear what "feed" means, but assuming it contains resources, it'd be the same:
HEAD /feed/id
It's tricky to say without seeing some examples to provide context.
But you could just have clients call HEAD /feed/images/{imageURI} (assuming that you might need to encode the imageURI). The server would respond with the usual HEAD response, or with a 404 error if the resource doesn't exist. You'd need to code some logic on the server to understand the imageURI.
Then the client either uses the image meta info in the head, or gracefully handles the 404 error and does something else (depending on the application I guess)
There's nothing "un-RESTful" about:
/feed/{feedId}?contains={imageURI}[,{imageURI}]
It returns the subset as specified. The resource, /feed/{feedid}, is a list resource containing a list of images. How is the resource returned with the contains query any different?
The URI is unique, and returns the appropriate state from the application. Can't say anything about the caching semantics of the request, but they're identical to whatever the caching semantics are of the original /feed/{feedid}, it simply a subset.
Finally, there's nothing that says that there even exists a /feed/{feedid}/image/{imageURL}. If you want to work with the sub-resources at that level, then fine, but you're not required to. The list coming back will likely just be a list of direct image URLS, so where's the link describing the /feed/{feedid}/image/{imageURL} relationship? You were going to embed that in the payload, correct?
How about setting up a ImageQuery resource:
# Create a new query from form data where you could constrain results for a given feed.
# May or may not redirect to /image_queries/query_id.
POST /image_queries/
# Optional - view query results containing URIs to query resources.
GET /image_queries/query_id
This video demonstrates the idea using Rails.