# Page cache e query string in Rails

**URL:** <https://www.ruby-forum.com/t/page-cache-e-query-string-in-rails/57445>\
**Category:** IT\
**Created:** [April 11, 2006, 12:51am UTC](https://www.ruby-forum.com/t/page-cache-e-query-string-in-rails/57445 "2006-04-11T00:51:34Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![Massimiliano\_M](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/839c29/32.png) [@Massimiliano\_M](https://www.ruby-forum.com/u/Massimiliano_M)\
**Post date:** [April 11, 2006, 12:51am UTC](https://www.ruby-forum.com/t/page-cache-e-query-string-in-rails/57445/1 "2006-04-11T00:51:34Z")

</div>

Prima che mi tiri la zappa sui piedi mettendo quanto segue in  
produzione, qualcuno con esperienza con il page cache in Rails può  
dirmi se c’è una trappola?

Leggevo che uno dei problemi del page cache è la query string. Una  
richiesta come /article/list?page=1 verrebbe messa in cache come  
/article/list.html, e le successive richieste ad /article/list?page=2,  
/article/list?page=3 restituirebbero sempre /article/list.html.

Ora, ho mezzo risolto facendo riscrivere a lighttpd  
/article/list?page=1 in /article/list/query/page=1 prima di passarlo a  
Rails (mezzo risolto nel senso che non ho ancora affrontato la  
riscrittura in lighttpd, ma il resto funziona). Nelle routes di  
Rails, ho qualcosa come:

map.connect(‘article/list/query/:query\_string’,  
:controller =\> ‘article’,  
:action =\> ‘list’)

In un before\_filter integro params[:query\_string] col resto di params  
e la vita procede come al solito. Poi, quando viene richiesta  
/article/list?page=1, Rails genera /article/list/query/page=1.html;  
quando viene richiesta /article/list?page=2, Rails genera  
/article/list/query/page=2.html, e così via. Alla seconda richiesta,  
queste pagine vengono servite staticamente.

Mi pare abbastanza banale, ma scorrazzando in giro per la rete non ho  
visto usare questo approccio. Dov’è la trappola?

Massimiliano

–  
blog: [http://blog.hyperstruct.net](http://blog.hyperstruct.net)  
sw: [http://dev.hyperstruct.net](http://dev.hyperstruct.net), [http://repo.hyperstruct.net](http://repo.hyperstruct.net)

---

<div class="post-metadata">

**Author:** ![Massimiliano\_M](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/839c29/32.png) [@Massimiliano\_M](https://www.ruby-forum.com/u/Massimiliano_M)\
**Post date:** [April 11, 2006, 6:25am UTC](https://www.ruby-forum.com/t/page-cache-e-query-string-in-rails/57445/2 "2006-04-11T06:25:53Z")

</div>

— Massimiliano M. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) ha  
scritto:

> /article/list?page=2,  
> /article/list?page=3 restituirebbero sempre  
> /article/list.html.
> 
> Ora, ho mezzo risolto facendo riscrivere a lighttpd  
> /article/list?page=1 in /article/list/query/page=1  
> prima di passarlo a  
> Rails (mezzo risolto nel senso che non ho ancora  
> affrontato la  
> riscrittura in lighttpd, ma il resto funziona).

perché non usi la cosa classica  
/article/list/page/2  
o magari, contaendola eliminando “page” ed altre cose  
in mezzo, che ne so per  
/article/id/1234/page/2  
direttamente  
/article/1234/2

?

–  
icq: #69488917  
blog: [http://riffraff.blogsome.com](http://riffraff.blogsome.com)

* * *

Yahoo! Mail: gratis 1GB per i messaggi e allegati da 10MB  
[http://mail.yahoo.it](http://mail.yahoo.it)

---

<div class="post-metadata">

**Author:** ![Massimiliano\_M](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/m/839c29/32.png) [@Massimiliano\_M](https://www.ruby-forum.com/u/Massimiliano_M)\
**Post date:** [April 11, 2006, 1:26pm UTC](https://www.ruby-forum.com/t/page-cache-e-query-string-in-rails/57445/3 "2006-04-11T13:26:03Z")

</div>

> perché non usi la cosa classica  
> /article/list/page/2  
> o magari, contaendola eliminando “page” ed altre cose  
> in mezzo, che ne so per  
> /article/id/1234/page/2  
> direttamente  
> /article/1234/2
> 
> ?

Per tenere separate le risorse ben definite e univocamente  
identificate nel corso del tempo (/article/1234) dalle variazioni di  
presentazione su un’aggregazione mutevole (?page=2) o su una risorsa  
stessa (?layout=tabular, etc.), e perché il path info, anche se più  
leggibile di una query string, dà meno libertà: /t/1/c/2 non è lo  
stesso di /c/2/t/1 mentre ?t=1&c=2 e ?c=2&t=1 lo sono. Cerco insomma  
di legarmi a una rappresentazione rigida solo per le componenti  
fondamentali e meno suscettibili di miei cambiamenti d’umore di qui a  
sei ore 😉 (di legarsi si tratta, quando l’alternativa è spezzare i  
link che puntano a te o un’API che conta su una certa interfaccia).

–  
blog: [http://blog.hyperstruct.net](http://blog.hyperstruct.net)  
sw: [http://dev.hyperstruct.net](http://dev.hyperstruct.net), [http://repo.hyperstruct.net](http://repo.hyperstruct.net)