Improve Rack::Static

[foonlyboy]

Hi at the rack

I'd like to enhance Rack::Static

I was looking for a way to easily serve static files in rails development.
This can easily be done with Rack::Static

But Rack::Static is very simplistic.
It only allows for a path from the url to be appended to a root path in the file system.
I'd like to improve on that.

My idea is to have a Hash of mappings: {}

• String => String: should behave as before, append the url path to root path
• Regexp => String: should match on regexp, and then apply gsub(regexp, string) (FIXME: avoid bad paths)
• • => Proc should execute Proc on mathc
• Proc => *: should match Proc on true
• Proc => Proc should allow the full freedom

Hint: in rails config/application.rb add:
config.middleware.insert_after(
ActionDispatch::Static,
Rack::Static, urls: ['static'], root: '/some-path/'
)

[ioquatix]

I think in most cases, it's better to have simple middleware that layer on top of each other.

Can you explain the problem you are thinking about solving? i.e. why do you want to make this improvement.

[foonlyboy]

Hi Samuel, thanks for your quick reply I fully agree with you, but then look into Rack::Static there is a lot of cruft in that. And the same applies to Rack::Files I'm just new with Rack, but I already got it, that it is not yet stackable? As far as I have learned, the rack modules are only executed sequentially? Maybe I'm heading for xrack? just kidding ... let's talk about that Best regards, Eike Dierks

…

On Sat, Mar 18, 2023 at 2:51 AM Samuel Williams ***@***.***> wrote: I think in most cases, it's better to have simple middleware that layer on top of each other. Can you explain the problem you are thinking about solving? i.e. why do you want to make this improvement. — Reply to this email directly, view it on GitHub <#2061 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AKLJCHR3X7BBLB7HPGCIAADW4UIILANCNFSM6AAAAAAV7FER3U> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[ioquatix]

If you have any thoughts about simplifying the existing code or even just extracting some code into a method which makes it easier to sub-class, both would be okay by me, we'd need to consider the specific changes on their own merits though.

[jeremyevans]

I wouldn't want to maintain all of this extra complexity in rack. You may want to copy the Rack::Static code and modify it to add the features you want, and then ship that in a gem for others to use.

[foonlyboy]

HI Samuel I came here from a simple problem. I'd like to explain the problem and my suggested solution. I have an app. The urls are based on /<path> I want to rebase the app. I want them to be based on /my-app/<path> I got it with the rails routes for the app but then also my static files need new routes. I had a custom solution for that, but then I learned, about Rack::Static (which obviously is the road to go) But here is the problem: Rack::Static simply concats the paths: /myapp/path resolves to /myapp/myapp/path I'd want to come up with some new code. I'm asking you to review it. I'd like to suggest an extension to the api, but that should be compatible with all legacy code. Rack::Static.new(mappings: {}) {String => String} would behave as before. {RegExp => String} would match on RegExp and route to gsub(RegExp, String) But then there's even more: {Proc => Proc} opens up all the routing, at your full disposal I fully understand that this is some new complication. But then look at the code. How does this interact with ::Files? This looks to me like a bad hack.

…

-- I have some new ideas for the rack. The rack should be stackable. I'm quite new at the rack. Best regards, Eike Dierks

On Sat, Mar 18, 2023 at 6:03 AM Samuel Williams ***@***.***> wrote: If you have any thoughts about simplifying the existing code or even just extracting some code into a method which makes it easier to sub-class, both would be okay by me, we'd need to consider the specific changes on their own merits though. — Reply to this email directly, view it on GitHub <#2061 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AKLJCHV2VBCCYI3RPJLNZMLW4U62ZANCNFSM6AAAAAAV7FER3U> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[jeremyevans]

Personally, I think Rack::Static is already a bit complicated. I'm not really in favor of proposals to make it even more complicated, especially proposals where the benefit of making it more complicated seem fairly minimal.

I don't think Rack::Static's integration with Rack::Files is a hack. That part works fairly well, IMO, especially how it can call Rack::Files multiple times in order to serve gzipped static files for better performance. Maybe I'm biased as I wrote that part.

I don't want to discourage you. If you submit a pull request with the proposed changes, we will consider it. However, know upfront there is a high likelihood that it would not be accepted, and be prepared for that if you do submit such a pull request. You have a higher chance of acceptance the simpler the patch is. If we don't accept it, you can still distribute it yourself.

One possibility that wouldn't be too complicated would be to support a block:

  use Rack::Static, urls: ['/myapp/static'], :root=>'public' do |path|
    # request path is yielded, modified path should be returned
  end

I'm not sure we would even accept that, but the more complex it gets, the less likely it is to be accepted.

[matthewd]

I think you're looking for Rack::URLMap, either to mount your entire existing application, or possibly combined with Rack::Cascade.

You might be able to use something like:

class Intercept < Rack::Cascade
  def initialize(main_app, injected_app)
    super([injected_app, main_app])
  end
end

# ...

use Intercept, Rack::URLMap("/myapp" => Rack::Static.new(...))

[foonlyboy]

Hi Jeremy, I do not want to change Rack::Static. This would be too complicated to stay compatible. But you got my idea. ~eike

…

On Tue, Mar 21, 2023 at 5:07 AM Jeremy Evans ***@***.***> wrote: Personally, I think Rack::Static is already a bit complicated. I'm not really in favor of proposals to make it even more complicated, especially proposals where the benefit of making it more complicated seem fairly minimal. I don't think Rack::Static's integration with Rack::Files is a hack. That part works fairly well, IMO, especially how it can call Rack::Files multiple times in order to serve gzipped static files for better performance. Maybe I'm biased as I wrote that part. I don't want to discourage you. If you submit a pull request with the proposed changes, we will consider it. However, know upfront there is a high likelihood that it would not be accepted, and be prepared for that if you do submit such a pull request. You have a higher chance of acceptance the simpler the patch is. If we don't accept it, you can still distribute it yourself. One possibility that wouldn't be too complicated would be to support a block: use Rack::Static, urls: ['/myapp/static'], :root=>'public' do |path| # request path is yielded, modified path should be returned end I'm not sure we would even accept that, but the more complex it gets, the less likely it is to be accepted. — Reply to this email directly, view it on GitHub <#2061 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AKLJCHUNQL4UPG7KTWINYODW5ESQPANCNFSM6AAAAAAV7FER3U> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[foonlyboy]

Hi Jeremy, I have to look at that. Back then, the rack was very easy. We should really keep the basic rack like that. But then, rack has the ability to stack modules. But up to now this is only sequential. I'd like to suggest that we stay sequential with the basic rack api, but to introduce xrack as a new api. I don't even know why we should need that. But I had problems rewriting the requests with basic rack. I would imagine, that we can have routers in the rack chain, to divert the routes to different handlers. I come up with a nice route filter, this is something that I want to show to you. ~eike

…

On Tue, Mar 21, 2023 at 5:07 AM Jeremy Evans ***@***.***> wrote: Personally, I think Rack::Static is already a bit complicated. I'm not really in favor of proposals to make it even more complicated, especially proposals where the benefit of making it more complicated seem fairly minimal. I don't think Rack::Static's integration with Rack::Files is a hack. That part works fairly well, IMO, especially how it can call Rack::Files multiple times in order to serve gzipped static files for better performance. Maybe I'm biased as I wrote that part. I don't want to discourage you. If you submit a pull request with the proposed changes, we will consider it. However, know upfront there is a high likelihood that it would not be accepted, and be prepared for that if you do submit such a pull request. You have a higher chance of acceptance the simpler the patch is. If we don't accept it, you can still distribute it yourself. One possibility that wouldn't be too complicated would be to support a block: use Rack::Static, urls: ['/myapp/static'], :root=>'public' do |path| # request path is yielded, modified path should be returned end I'm not sure we would even accept that, but the more complex it gets, the less likely it is to be accepted. — Reply to this email directly, view it on GitHub <#2061 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AKLJCHUNQL4UPG7KTWINYODW5ESQPANCNFSM6AAAAAAV7FER3U> . You are receiving this because you authored the thread.Message ID: ***@***.***>