responce на запрос HTTP DELETE возвращает данные, которые not modified.
10.3.5 304 Not Modified
If the client has performed a conditional GET request and access is allowed, but the document has not been modified, the server SHOULD respond with this status code. The 304 response MUST NOT contain a message-body, and thus is always terminated by the first empty line after the header fields.
The response MUST include the following header fields:
— Date, unless its omission is required by section 14.18.1
If a clockless origin server obeys these rules, and proxies and clients add their own Date to any response received without one (as already specified by [RFC 2068], section 14.19), caches will operate correctly.
— ETag and/or Content-Location, if the header would have been sent
in a 200 response to the same request
— Expires, Cache-Control, and/or Vary, if the field-value might
differ from that sent in any previous response for the same
variant
If the conditional GET used a strong cache validator (see section 13.3.3), the response SHOULD NOT include other entity-headers. Otherwise (i.e., the conditional GET used a weak validator), the response MUST NOT include other entity-headers; this prevents inconsistencies between cached entity-bodies and updated headers.
If a 304 response indicates an entity not currently cached, then the cache MUST disregard the response and repeat the request without the conditional.
If a cache uses a received 304 response to update a cache entry, the cache MUST update the entry to reflect any new field values given in the response.
Т.о. делаем простое предположение: application-server вернул 200, веб сервер вернул 304, хром увидел 304 и закешировал
Логов веб сервера в тикете не видно, какой веб сервер и какие настройки не понятно.
У rails по дефолту был нормальный механизм REST-взаимодействия. С самых ранних версий scaffold был RESTfull. Только в версии 1.0 было не все так хорошо.
После версии 1.0 было писать на рельсах только RESTfull приложения, всегда. «Покажи мне свой routes.rb, и я скажу кто ты» — шутка 2007-го года про непонимающих REST. Версия rails была 1.2 уже рестфул.
ActiveResource::Base заработало так как вы описываете в версии 2.0 в декабре 2007 года.
Ожидаемо.
Я недавно получил аналогичные результаты, только делал это вручную: habrahabr.ru/post/147252/
Было
Views: 490.9ms | ActiveRecord: 14.4ms
Стало
Views: 12.9ms | ActiveRecord: 17.1ms
Как ни старался, я не нашел воплей боли из-за смены версии Ruby на хабре, только радость от нового релиза. Истерички не в счет — истерички вообще боятся изменений.
У меня смартфон, грамотные телефонные скилы, опыт руководства, опыт продаж и я регулярно покупаю время. И всяких разных знакомы умеющих делать специфические штуки — целый город. Важно уметь применять нужный инструмент в нужное время.
А с автором мы встретимся в кабачке и опрокинем чарку, нужно же и отдыхать иногда.
Да решений милион, но покупка мыши стоимостью превышающей среднюю стоимость работы в стране — неэффективна.
1. версия руби и версия рельс четко прописана в проекте. Т.о. без вашего ведом код не может вдруг начать подругому работать
2. ветка 2.3.6 — 2.3.11 прошло более 3-х лет
3.0.х — 3.1.х — параллельная ветка, все что задекларировано 2.3 как неработающее в 3х неработает
Переезд работающего проекта с 2.3 на 3х занимает менее недели в хучшем случае. Конечно если у вас в проекте километры спагети и быдлокод — переезд затрудняется. Список депрецированных функций можно получить из лога, и если избавится от всех варнингов деприкации переезд с ветки 2.3 на 3.0 проходит в считанные минуты
3. мой проект, которому больше года, спокойно перелез с 3.0.непомню, на 3.1.1 за 10 минут, с одним багом, по моей вине.
4. смена версии руби вообще может не повлиять на поведение системы
5. Тесты наше все — не прошел тест — поправили
1. Увтор утверждает, что потратил два часа, откуда 6?
2. Даже если я не уверенный пользователь паяльника, то дешевле позвонить автору и заказать работу, чем покупать мышь за 500-700 рублей, а потом еще и софт писать.
3. Поход в магазин тоже потратит время(деньги), телепортацию еще не изобрели.
Мой папа трансформаторы чертит руками быстрее чем я в каде, потому, что он знает, как чертить трансофрматоры. А еще, я знал одну древнюю старушку в проектном институте, так она четырнадцатым кеглем по а3 ватману, да карандашиком заточенным строчит быстрее, чем я набираю на клавиатуре, уже давно, слепым методом, и опечаток у нее вообще нет.
10.3.5 304 Not Modified
If the client has performed a conditional GET request and access is allowed, but the document has not been modified, the server SHOULD respond with this status code. The 304 response MUST NOT contain a message-body, and thus is always terminated by the first empty line after the header fields.
The response MUST include the following header fields:
— Date, unless its omission is required by section 14.18.1
If a clockless origin server obeys these rules, and proxies and clients add their own Date to any response received without one (as already specified by [RFC 2068], section 14.19), caches will operate correctly.
— ETag and/or Content-Location, if the header would have been sent
in a 200 response to the same request
— Expires, Cache-Control, and/or Vary, if the field-value might
differ from that sent in any previous response for the same
variant
If the conditional GET used a strong cache validator (see section 13.3.3), the response SHOULD NOT include other entity-headers. Otherwise (i.e., the conditional GET used a weak validator), the response MUST NOT include other entity-headers; this prevents inconsistencies between cached entity-bodies and updated headers.
If a 304 response indicates an entity not currently cached, then the cache MUST disregard the response and repeat the request without the conditional.
If a cache uses a received 304 response to update a cache entry, the cache MUST update the entry to reflect any new field values given in the response.
Т.о. делаем простое предположение: application-server вернул 200, веб сервер вернул 304, хром увидел 304 и закешировал
Логов веб сервера в тикете не видно, какой веб сервер и какие настройки не понятно.
После версии 1.0 было писать на рельсах только RESTfull приложения, всегда. «Покажи мне свой routes.rb, и я скажу кто ты» — шутка 2007-го года про непонимающих REST. Версия rails была 1.2 уже рестфул.
ActiveResource::Base заработало так как вы описываете в версии 2.0 в декабре 2007 года.
Я недавно получил аналогичные результаты, только делал это вручную:
habrahabr.ru/post/147252/
Было
Views: 490.9ms | ActiveRecord: 14.4ms
Стало
Views: 12.9ms | ActiveRecord: 17.1ms
Ну например: «Ваши зубы белее на 20%», а «был цвет RAL1013, а стал RAL9003»
Самому никак, человек он такое существо, которое обожает себя обманывать и жить в этом обмане.
А с автором мы встретимся в кабачке и опрокинем чарку, нужно же и отдыхать иногда.
Да решений милион, но покупка мыши стоимостью превышающей среднюю стоимость работы в стране — неэффективна.
2. ветка 2.3.6 — 2.3.11 прошло более 3-х лет
3.0.х — 3.1.х — параллельная ветка, все что задекларировано 2.3 как неработающее в 3х неработает
Переезд работающего проекта с 2.3 на 3х занимает менее недели в хучшем случае. Конечно если у вас в проекте километры спагети и быдлокод — переезд затрудняется. Список депрецированных функций можно получить из лога, и если избавится от всех варнингов деприкации переезд с ветки 2.3 на 3.0 проходит в считанные минуты
3. мой проект, которому больше года, спокойно перелез с 3.0.непомню, на 3.1.1 за 10 минут, с одним багом, по моей вине.
4. смена версии руби вообще может не повлиять на поведение системы
5. Тесты наше все — не прошел тест — поправили
2. Даже если я не уверенный пользователь паяльника, то дешевле позвонить автору и заказать работу, чем покупать мышь за 500-700 рублей, а потом еще и софт писать.
3. Поход в магазин тоже потратит время(деньги), телепортацию еще не изобрели.