Unable to save header and/or footer due to 404 error

I'm unable to replicate this. Can you export a copy of your view so we can try to import it and see if we can replicate the problem?

One guess might be, given what you've said, is that you've got a module with some leftover debug on filters?

I too am trying to add a footer with full HTML filter and get the similar error with this code:

<a rel="nofollow" class="print-page" title="Display a printer-friendly version of this page." href="http://persidium.com/cod/print/program/session-schedule"><img height="16" width="16" class="print-icon print-icon-margin" title="Printer-friendly version" alt="Printer-friendly version" src="http://persidium.com/cod/sites/all/modules/print/icons/print_icon.gif">Printer-friendly version</a>

If I remove the , then it works. Alternately, if I just add the image as an standalone image, then it works too, but of course the printer icon is not part of the link.

<img height="16" width="16" class="print-icon print-icon-margin" title="Printer-friendly version" alt="Printer-friendly version" src="http://persidium.com/cod/sites/all/modules/print/icons/print_icon.gif" /><a rel="nofollow" class="print-page" title="Display a printer-friendly version of this page." href="http://persidium.com/cod/print/program/session-schedule">Printer-friendly version</a>

I have attached the view as .txt file and I am trying to add the top html to the Schedule page of that view. Also have attached a screenshot of the error.

Thansk for any assistance!

i ran into the same error with the header.

it also only happened when html was added to the header.

i tried using the "Full html" filter, the "php code" filter and the other default drupal filter, "Filtered HTML"

I also tried disabling javascript in the views UI (as I first saw this as an ajax error)

oddly, it only happens when i had an html element nested inside of another, and if the parent element has a class with a value designated in double quotes.

so this worked:

<h1 class="test">title</h1>

and so did single quotes:

<h1 class='test'><span>title</span></h1>

but this didn't work (results in 404):

<h1 class="test"><span>title</span></h1>

there's got to be a failing regex somewhere, but i don't think it's the input filter because it happened on all 3 default input filters. it seems to me that it's more likely that the escapes for input processing on double quotes and html entities work by themselves, but fail when the input is in the right combination:

child html element (any element: span, p, div) wrapped by a parent element with attribute value wrapped in double quotes (class="foo") and child

However, i've been using views 2 for like 2 years and never saw this until recently, when I had imported a views 1 view from drupal 5 with the convert tool when moving from drupal 5 to drupal 6.

to help debug, after i got it working in drupal 6, i tried to export, and then tried to import to a new view.

i got a 404 doing that, too. but below is the exported view.

here's the view export:

$view = new view;
$view->name = 'Articles_View';
$view->description = '';
$view->tag = '';
$view->base_table = 'node';
$view->core = 0;
$view->api_version = '2';
$view->disabled = FALSE; /* Edit this to true to make a default view disabled initially */
$handler = $view->new_display('default', 'Defaults', 'default');
$handler->override_option('sorts', array(
  'created' => array(
    'id' => 'created',
    'table' => 'node',
    'field' => 'created',
    'order' => 'DESC',
    'granularity' => 'second',
  ),
));
$handler->override_option('filters', array(
  'status' => array(
    'id' => 'status',
    'table' => 'node',
    'field' => 'status',
    'value' => '1',
  ),
  'type' => array(
    'id' => 'type',
    'table' => 'node',
    'field' => 'type',
    'value' => array(
      0 => 'article',
    ),
    'operator' => 'in',
  ),
  'tid' => array(
    'id' => 'tid',
    'table' => 'term_node',
    'field' => 'tid',
    'value' => array(
      0 => '144',
      1 => '82',
    ),
    'vid' => 3,
    'operator' => 'or',
    'type' => 'select',
  ),
));
$handler->override_option('access', array(
  'type' => 'none',
  'role' => array(),
  'perm' => '',
));
$handler->override_option('cache', array(
  'type' => 'none',
));
$handler->override_option('title', 'All Articles');
$handler->override_option('header', '<h1>Features</h1>
<div class=\'RSS_button\'>
<a href=\'/rss/article\'>RSS</a>
</div>');
$handler->override_option('header_format', '3');
$handler->override_option('header_empty', 0);
$handler->override_option('footer_format', '3');
$handler->override_option('footer_empty', 0);
$handler->override_option('empty_format', '3');
$handler->override_option('items_per_page', '10');
$handler->override_option('use_pager', '1');
$handler->override_option('row_plugin', 'node');
$handler->override_option('row_options', array(
  'teaser' => TRUE,
  'links' => TRUE,
));
$handler = $view->new_display('page', 'Page', 'page_1');
$handler->override_option('path', 'articles');
$handler->override_option('menu', array(
  'type' => 'none',
  'title' => '',
  'description' => '',
  'weight' => 0,
  'name' => 'navigation',
));
$handler->override_option('tab_options', array(
  'type' => 'none',
  'title' => '',
  'description' => '',
  'weight' => 0,
  'name' => 'navigation',
));

FWIW, If you're using a theme that has the option enabled of "rebuild theme registry on every page load," There's an message in the JSON response header that seems to interfere with anything AJAX-y in views_ui. It's telling you that the option should not be on in a production environment.

I disabled that option in the theme's settings page, and all is working again.

I don't have any direct proof that the header is related to the encumbrance I encountered.

But, maybe that'll help your situation?

(Would be cool if these played nicely though.)

Also, might try changing your default theme and admin-theme to see if that lets you make the change.

Wow I never had seen this before, but this actually turned out to be a server configuration problem. I'm on a shared host, and there was some change within mod_security -- a somewhat similar issue actually occured with the same apache module on a different site (not even drupal)

Anyway.. See this post for details:
http://drupal.org/node/110219