Open ghost opened 4 years ago
RFC 2296 is specifically about the RVSA version 1.0 (i.e., run when Negotiate: 1.0
is specified). We are not going to implement any other version of RVSA. Presence of this header means we will specifically use the algorithm described in section 3.3 to combine various aspects for each available representation to calculate their overall quality and identify the winner. If we still have a tie for the first position, then we will return 300 Multiple Choice
response. Absence of transparent content negotiation related headers means it is either going to be a Proactive or a Reactive negotiation instead. Revisiting Lecture 7 slides might help you understand what I mean.
Let me know if it helps or if you need more information on anything specific.
Yes, this does make sense now. Seeing section 3.3 clears up what RSVA 1.0 should be doing.
The assignment description specifies that we should send a
300 Multiple Choice
response when there are multiple valid representations and the user agent sendsNegotiate: 1.0
(or the q values are in a tie).I have read most of RFC 2295 for the Negotiate header and RFC 2296 for specifically rsva 1.0. I currently don't understand is precisely what properly supporting rsva 1.0 should change as opposed to it not being specified in the request. Could you offer some more information or guidance?