On Fri, Sep 5, 2008 at 7:49 PM, Michael Greb <[EMAIL PROTECTED]> wrote: > On Sep 5, 2008, at 4:29 AM, Gisle Aas wrote: >> >> Hi Michael, >> >> This seems like a very useful addition to libwww-perl. I have been >> wanting a mode where $response->as_string would show responses exactly >> as they where received without adding, or reordering of the headers >> or even fix up the casing for the header field names. A patch like >> yours should make this much easier. >> >> Your patch does not address the preserving-of-case for header filed >> names. Is that not required for your signing server? > > We join the values of the signed headers without the name of the header so > case doesn't matter for us. That said, it certainly makes sense to store > the headers in their original case in _wire_order rather than the normalized > version. Should the header_field_names and the pass method both then return > the headers in the original case when dont_sort is passed?
I think I would prefer to leave 'header_field_names' alone and only support original field order and field name casing for the 'scan' and 'as_string' methods. This since 'header_field_names' is documented to not repeat field names, while the others do. >> It also seems your approach makes it hard to deal correctly with >> repeated headers mixed in with others; for instance something like >> this ugly response: >> >> 200 OK >> Server: Fool/1.0 >> content-encoding : >> gzip >> Content-Type: text/plain; charset="UTF-8" >> Content-Encoding: base64 >> Date: Fri Sep 5 10:24:37 CEST 2008 >> >> H4sICETrwEgAA3h4eADLSM3JyVcozy/KSVHkAgC0r9cBDQAAAA== >> >> Your thoughts? > > > I'm not sure exactly what the right way to handle this would be. > header_field_names is speced in the docs as returning only the distinct > header field names. Perhaps rather than an optional dont_sort argument this > should be a new method, something like 'wire_header_fields' that returns all > headers in the original case and order including duplicates? This also > relates to the as_string method and your desire to have a mode that returns > things in thier original form. As I said above I would solve the problem by not changing 'header_field_names' at all. Do you feel the scan interface isn't good enough for your use case? > Writing code is easy, it's deciding how that code should behave that is the > hard part. True; and in this case we need to define what happens when fields are modified with 'push', 'set' or 'init' and 'remove' as that's the API that modify stuff. Let me suggest the following definition of the behaviour: - 'push' always append the field at the end of all headers. multiple occurrences of a field name do not have to be consecutive. - 'init' either does nothing or it works like 'push'. - 'remove' will always remove all concurrences of a field. - 'set' will work like 'push' if no other occurrence of the field exists. - 'set' will update the first occurrence if the field exists (and remove all other occurrences). if multiple field values is provided with 'set' they are basically all injected at the location of the first existing value. You want to try to implement this? --Gisle
