RE: [reSIProcate] Smarter accept header validation in dum?
After thinking about this some more - I think I will just leave the API's as
is for now.
If a UA supports a particular Content-Encoding or Language for one request,
there is no reason that it should not support it for other requests. I
agree it would add flexibility, but it would also make it more difficult to
configure - ie. you would have to set the supported language / content
encoding for every request. So unless there is strong opposition to this -
I won't bother changing the current api's for supported Content-Encoding and
Content-Language at this time.
Thanks,
Scott
-----Original Message-----
From: Scott Zuk [mailto:szuk@xxxxxxxxxxxxxxx]
Sent: Thursday, February 03, 2005 5:31 PM
To: resiprocate-devel@xxxxxxxxxxxxxxxxxxx
Subject: Re: [reSIProcate] Smarter accept header validation in dum?
Looks good, thanks.
As for the Content-Encoding and Content-Language validation, I think they
should be request specific too. It seems a bit odd to me why anyone who
spoke two languages would for example want to only accept one for Message
and
the other for Invite, but it should be perfectly valid. I can't imagine a
huge need for this functionality, but at the very least changing the current
behaviour would keep the api consistent with the new mime type validation.
Regards,
~Scott
On February 3, 2005 9:12 am, Scott Godin wrote:
> Yup - I agree, I missed that problem from your original email - I'll fix
> it. This whole accept header validation thing is poorly spec'ed out in
> RFC3261. For reference I've included some attachments from previous
> discussions.
>
> Do you think that Content-Encoding and Content-Language validation should
> also be per Request Method? I'm thinking they should be request specific.
>
> Thanks,
>
> Scott
>
> -----Original Message-----
> From: Scott Zuk [mailto:szuk@xxxxxxxxxxxxxxx]
> Sent: Wednesday, February 02, 2005 4:54 PM
> To: resiprocate-devel@xxxxxxxxxxxxxxxxxxx
> Subject: Re: [reSIProcate] Smarter accept header validation in dum?
>
> I haven't tried out the new code yet, but from the commit diff it looks
> like
>
> the situation I described in my original post will still occur, although
it
> is now solvable.
>
> In DialogUsageManager::validateAccept() the for loop that checks the
Accept
> values will sill bail with a 406 the first time it sees an unacceptable
> value. Of course it had to be this way with the old code, but now that
> your
>
> fix relates mimes to request types I think the loop should only send a 406
> if
> zero Accept header values match. The request should be acceptable if only
> one mime type matches even if all the rest don't, correct?
>
> Thanks,
> ~Scott
>
> On February 2, 2005 1:15 pm, Scott Godin wrote:
> > I've completed making changes for this and have committed to the teltel
> > branch. Supported MimeTypes are now Request specific.
> >
> > -----Original Message-----
> > From: Scott Godin
> > Sent: Friday, January 21, 2005 4:08 PM
> > To: 'Scott Zuk'; resiprocate-devel@xxxxxxxxxxxxxxxxxxx
> > Subject: RE: [reSIProcate] Smarter accept header validation in dum?
> >
> > I agree with you, and I like your suggestion. I will add this to my
task
> > list.
> >
> > For now - you could just disable Accept validation completely - by
> > calling profile method:
> > validateAcceptEnabled() = false;
> >
> > -----Original Message-----
> > From: Scott Zuk [mailto:szuk@xxxxxxxxxxxxxxx]
> > Sent: Thursday, January 20, 2005 1:23 AM
> > To: resiprocate-devel@xxxxxxxxxxxxxxxxxxx
> > Subject: [reSIProcate] Smarter accept header validation in dum?
> >
> > Hi,
> >
> > I'm trying to get my dum based program to talk with windows messenger,
> > however
> > the way the dum handles accept header validation causes all subscribe
> > requests sent by windows messenger to be rejected.
> >
> > WM sends subscribes with an Accept header containing the mime types
> > "text/xml+msrtc.pidf" "application/xpidf+xml" and "application/pidf+xml"
>
> in
>
> > that order. My app is set to reply using only "application/pidf+xml" so
>
> in
>
> > theory this should be fine. The problem though is that
> > DialogUsageManager::validateAccept() sends a 406 failure on the first
> > unrecognized mime type it sees, even if there is a valid one later in
the
> > list. Is this the intended behaviour?
> >
> > I think the dum should take into account the message type when
> > determining valid accept mime types. Adding a method to Profile that
> > would allow something like
> > addSupportedMimeType(Mime("application", "pidf+xml"), SUBSCRIBE) might
be
> > usefull. Are there any current plans to implement something like this
in
> > resiprocate?
> >
> > Thanks,
> > ~Scott
> > _______________________________________________
> > resiprocate-devel mailing list
> > resiprocate-devel@xxxxxxxxxxxxxxxxxxx
> > https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel
>
> _______________________________________________
> resiprocate-devel mailing list
> resiprocate-devel@xxxxxxxxxxxxxxxxxxx
> https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel
_______________________________________________
resiprocate-devel mailing list
resiprocate-devel@xxxxxxxxxxxxxxxxxxx
https://list.sipfoundry.org/mailman/listinfo/resiprocate-devel