[
https://issues.apache.org/jira/browse/SLING-3496?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13962621#comment-13962621
]
Nan Fan commented on SLING-3496:
I understand your points, it makes sense but a little bit
Proposal sounds good to me. I would agree to move this to a plugin that gets
the accept header (is there anything else?) and can update any existing
selectors/extension/suffix (the PathInfo) parsed already.
void updatePathInfo(String[] accepts, PathInfo pathInfo);
Notes:
- accept header alr
On 2014-04-07 15:59, Felix Meschberger wrote:
Hi
Ok, it is not exactly arbitrary logic. Turns out that content types of the style
application/someformat+somesyntax
are pretty common (see [1], [2]). Also when talking about REST-ful APIs I
expect some application on the other (client) side an
+1 for cachable requests with the Vary-header!
Regards
Julian
On Mon, Apr 7, 2014 at 4:52 PM, Robert Munteanu wrote:
> On Mon, Apr 7, 2014 at 5:50 PM, Marius Petria wrote:
>> Just a question on this. Isn't pushing the format information into headers
>> making caching more complicated?
>
> It _
Hi Felix
> As to other headers: This is about content type negotiation which involves as
> per the HTTP spec the Accept header.
The HTTP 1.1 spec defines the following headers for
content-negotiation, I quote: "Accept (section 14.1), Accept- Charset
(section 14.2), Accept-Encoding (section 14.3)
Felix Meschberger wrote:
* Extension (and optional selectors) have not derived from the URL yet
One of the lessons I think I see from how selectors & extensions are working in
the face of creation requests to non-existent resources is that there should be
a way to *override* what is derived from
On Mon, Apr 7, 2014 at 5:50 PM, Marius Petria wrote:
> Just a question on this. Isn't pushing the format information into headers
> making caching more complicated?
It _should_ work if Sling adds the 'Vary: Accept' header.
Robert
>
> Regards,
> Marius
>
>> -Original Message-
>> From: C
Just a question on this. Isn't pushing the format information into headers
making caching more complicated?
Regards,
Marius
> -Original Message-
> From: Carsten Ziegeler [mailto:cziege...@apache.org]
> Sent: Monday, April 07, 2014 4:28 PM
> To: dev@sling.apache.org
> Subject: Re: Suppor
I haven't thought in detail about this, but if we go such a way we should
think of improving the resolve() method of the resource resolver in some
way.
Today, when a request comes in, the full path is used to find the resource,
it's then shortened until an existing resource is found. If we have a
r
Hi
Ok, it is not exactly arbitrary logic. Turns out that content types of the style
> application/someformat+somesyntax
are pretty common (see [1], [2]). Also when talking about REST-ful APIs I
expect some application on the other (client) side and this will in general not
come with a list of
[
https://issues.apache.org/jira/browse/SLING-3496?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13961848#comment-13961848
]
Carsten Ziegeler commented on SLING-3496:
-
Thanks for the issue and the informatio
Hi all,
On 3 April 2014 17:14, David Bosschaert wrote:
> On 3 April 2014 16:15, Bertrand Delacretaz wrote:
>> Note that you might find some quite old stuff under /samples, if you
>> have suggestions for things that should be archived or at least marked
>> obsolete let's hear them!
>
> I'm planni
On Mon, Apr 7, 2014 at 11:20 AM, Julian Sedding wrote:
..
> - other headers, e.g. Accept-Language, could also be easily supported...
Good point, it shows that plugins are welcome in this area.
-Bertrand
I agree with Bertrand. Generally, I'm in favor of supporting the Accept header.
However coding an arbitrary logic into Sling Engine (or some other
core bundle) does not sound good to me.
The benefits of a pluggable solution would be
- preservation of modularity and
- the implementation of some "s
[
https://issues.apache.org/jira/browse/SLING-3496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Nan Fan updated SLING-3496:
---
Description:
The change in SLING-3482 causes a problem that synthetic resource cannot be
resolved, but its c
On Mon, Apr 7, 2014 at 9:58 AM, Felix Meschberger wrote:
> ...I would prefer to not go over board, at least not initially, and keep it
> simple and covering simple use cases
I like simple but what I object to is burning this into the Sling core
- what you suggest is based on somewhat arbitra
Hi
Am 07.04.2014 um 09:42 schrieb Bertrand Delacretaz :
> Hi,
>
> On Mon, Apr 7, 2014 at 9:24 AM, Felix Meschberger wrote:
>> ...TL;DR: Use Accept header to set request's selectors and extension. So an
>> example Accept content type
>> of "application/x-players+json" would set the selector str
Hi,
On Mon, Apr 7, 2014 at 9:24 AM, Felix Meschberger wrote:
> ...TL;DR: Use Accept header to set request's selectors and extension. So an
> example Accept content type
> of "application/x-players+json" would set the selector string to "players"
> and the extension to "json"...
I like the idea
Hi all
TL;DR: Use Accept header to set request's selectors and extension. So an
example Accept content type of "application/x-players+json" would set the
selector string to "players" and the extension to "json".
We always touted Sling to be a platform for REST-ful web applications. But we
chea
19 matches
Mail list logo
