I have an issue. I have implemented a custom stream wrapper using hook_file_stream_wrappers. The CDN module doesn't respect my custom stream wrapper and always puts the CDN url in front of my uri. This is an issue because my files are behind an access control system and I need the option to add the cdn url or not too. Would it be possible to add a hook of respected stream wrappers?

#8 custom_stream_wrappers-1863310-8.patch815 bytesWim Leers
PASSED: [[SimpleTest]]: [MySQL] 50 pass(es). View
Members fund testing for the Drupal project. Drupal Association Learn more


Wim Leers’s picture

Status: Active » Postponed (maintainer needs more info)


So you have some kind of custom scheme, such as "myscheme" instead of "public" or "http" or "https"? Or are you just using Drupal's "private files" support?

Does the CDN module currently successfully serve these files from the CDN?

pwaterz’s picture

Category: feature » bug
Status: Postponed (maintainer needs more info) » Active

Thanks for your response!

Yes I am using my own custom scheme hwfilestream:\\, yes it does successfully server the file. But I have custom logic in my stream wrapper class that I want to be able to say server from the CDN or not to server from the CDN, but I have no way of stopping the CDN module from sticking the origin pull domain in from of the url. Even if i return a full url, including http:\\ from my class, it still puts the cdn domain in front of it.

I just noticed in cdn.module on line 93 you have

 // Attempt to get an external URL using the appropriate wrapper.
      if ($wrapper = file_stream_wrapper_get_instance_by_uri($original_uri)) {
        $uri = str_replace($GLOBALS['base_url'] . '/', '', $wrapper->getExternalUrl());

Which essentially just ignores a stream wrapper the returns a full path. I dont think CDN module should hijack all stream wrappers. Only stream wrappers that return relative urls.

Wim Leers’s picture

#2: that's a sharp, excellent observation! However, if memory serves me well, that is unfortunately an absolute necessity, because Drupal's default "public://" stream wrapper in fact always returns absolute URLs…

pwaterz’s picture

hmm....going to have to think about this one :)

pwaterz’s picture

It almost seems like there should be a setting for enabled or disable stream wrappers. If that the point of stream wrappers to be able to differentiate different collections of files.

Wim Leers’s picture

I think you're the first one to use streamwrappers that are not the built-in "public://" or "private://" ones :)

AFAICT, you're right. The only thing I can think of that can help solve this, is checking the file URL being altered against a list of allowed schemes. The default list should include 'http', 'https' and 'public'. It should exclude 'private'. You could then also exclude 'hwfilestream'. We must use http://api.drupal.org/api/drupal/includes%21file.inc/function/file_get_s... for that.

One note: is 'hwfilestream' marked as a local or remote stream wrapper? If it's the latter, we may want to consider using that distinction instead.

P.S.: cool, you're from Palo Alto! :) I was there last year for an internship :)

pwaterz’s picture

Hmm..i think checking the local flag is a good idea. That way you dont need to have a settings page and other stream wrappers can control weather or not the cdn is invoked. Ill try and work up a patch in the next few days.

Nice, PA is great! We are looking for people if your interested!

Wim Leers’s picture

Title: CDN module overrides custom stream wrappers » CDN module should know how to deal with custom stream wrappers
Version: 7.x-2.5 » 7.x-2.x-dev
Component: Origin Pull mode » Module
Category: bug » feature
Status: Active » Needs review
815 bytes
PASSED: [[SimpleTest]]: [MySQL] 50 pass(es). View

#7: Hah, thanks :) I declined a job at Facebook already precisely because I don't want to emigrate from Belgium, so… I'm going to have to respectfully decline again :) Thanks though!

pwaterz’s picture

Haha worth a try, always looking for some good talent! Patch looks good by the way!

mermentau’s picture

The patch works for me on Amazon S3 content.

Wim Leers’s picture

Assigned: Unassigned » Wim Leers
Status: Needs review » Reviewed & tested by the community

Great, thanks! :)

Wim Leers’s picture

Status: Reviewed & tested by the community » Fixed

(This is on the edge of feature request vs. bug report.)

Thanks to the feedback in #10: committed!


Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.