[patch] Fix CSV output in avail.c revisited

[Sven-Göran Bergh]

> Från: Andreas Ericsson <ae at op5.se>

>Till: Sven-Göran Bergh <svengbergh-nagiosdevel at yahoo.com> 
>Kopia: Nagios Developers List <nagios-devel at lists.sourceforge.net> 
>Skickat: tisdag, 10 januari 2012 10:07
>Ämne: Re: [Nagios-devel] Fix CSV output in avail.c
> 
>On 01/09/2012 06:38 PM, Sven-Göran Bergh wrote:
>>> Från: Andreas Ericsson<ae at op5.se>
>> 
>>> Till: Sven-Göran Bergh<svengbergh-nagiosdevel at yahoo.com>; Nagios Developers List<nagios-devel at lists.sourceforge.net>
>>> Kopia:
>>> Skickat: måndag, 9 januari 2012 16:38
>>> Ämne: Re: [Nagios-devel] Fix CSV output in avail.c
>>>
>>> On 11/28/2011 09:04 PM, Sven-Göran Bergh wrote:
>>>>   Hi,
>>>>
>>>>   attached patch fix the CSV output from avail.c
>>>>   to comply better with RFC-4180, see
>>>>
>>>>  http://www.ietf.org/rfc/rfc4180.txt.
>>>>
>>>>   Content-type now is Text/csv, so the browser
>>>>   presents a view/save dialog.
>>>
>>> How is this an improvement over just hitting Ctrl+S once the page
>>> has loaded? Personally, I detest when pages I *know* is plain text
>>> forces me to click something just in order to either view or save,
>>> when saving after it's viewed is so simple anyway.
>> 
>> Two of the reasons to why the patch was written in the first place
>> are:
>> - The Nagios CGIs are embedded in another GUI app that AJAX-load
>>    the CGI pages in a div element. To get a stand alone window that
>>    is possible to Ctrl+S save would mean a lot of tweaking, while the
>>    result would violate an otherwise smooth GUI.
>> 
>> - Our users are no techies. An additional step would require a manual
>>    (yah, no kidding) that no one reads anyway. They just want to get
>>    the data directly into a spreadsheet with as little hassle as
>>    possible.
>> 
>>>>   Likewise, CRLF is used.
>>>>
>>>
>>> This could be tricky. I know there are parsers out there that handle
>>> the Nagios-style CSV format, and if they break because we suddenly
>>> choose to go strict with the style we use, we shove a broomstick up
>>> our asses for no gain what so ever.
>>>
>>> So... Have you verified that this patch doesn't break anything, or
>>> is that supposed to be an exercise for one of the maintainers? If
>>> you haven't done it, it's unlikely to get done at all, and in that
>>> case the CRLF part of the patch will almost certainly have to be
>>> dropped or modified so that line-endings are given as a character
>>> sequence by the user instead.
>> 
>> No, I have not run any additional tests. Just a normal compilation
>> and our own in-house parser. Any specific parser/test you are thinking
>> about? Hmm, I will try to look into a solution with desired line-
>> ending supplied as a URI query variable that defaults to LF-only.
>> Feel free to drop the CRLF part for the moment. I'll be back.
>> 
>
>I've done so. Since the only editor I know of that screws up LF/CRLF
>differences in Windows is Notepad, I'm not overly fussed about this
>and would rather just ignore it completely. I know all the major
>office suites (Open, Libre and MS) handle LF line-endings just fine
>in csv input though.



I hear you. The patch is now revamped to listen to the user. By default
nothing is changed.

Summary:
- CSV output is either as today, or strict compliant with RFC4180.
  No in betweens.

- If the URI query parameter "csvstrict" is supplied together with
  csvoutput. The output will be strict according to RFC4180.
- Otherwise, the output is the same as today.

- An additional checkbox for csvstrict has been added

- Output according to RFC4180 has the following changes compared to the
  traditional output:  - HTTP, changed header: Content-Type: text/csv; header=present
  - HTTP, new header: Content-Disposition: attachment; filename=availability.csv
  - CSV, line-ending is CRLF
  - CSV, no spaces inside CSV fields


Hope you like this better. The patch is against the 3.3.1 release.

Bgrds
/S-G
-------------- next part --------------
A non-text attachment was scrubbed...
Name: nagios-3.3.1_cgi_avail.c-RFC4180.patch
Type: application/octet-stream
Size: 21918 bytes
Desc: not available
URL: <https://www.monitoring-lists.org/archive/developers/attachments/20120110/49c8c62d/attachment.obj>
-------------- next part --------------
------------------------------------------------------------------------------
Write once. Port to many.
Get the SDK and tools to simplify cross-platform app development. Create 
new or port existing apps to sell to consumers worldwide. Explore the 
Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join
http://p.sf.net/sfu/intel-appdev
-------------- next part --------------
_______________________________________________
Nagios-devel mailing list
Nagios-devel at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nagios-devel