SOLVED: ASP-generated XML not valid when URL has query string. How to fix?

See more:

VB

ASP.NET

XML

I have a page that is invoked as Test.aspx?id=102 that does this:

Protected Sub Page_Load(ByVal sender As Object, _
ByVal e As System.EventArgs)
    Dim ThisId As String = Request.QueryString("id")

    Dim Doc As XmlDocument = GenerateData(ThisId)

    Response.Buffer = True
    Response.ClearContent()
    Response.ClearHeaders()
    Response.ContentType = "text/xml"
    Response.Write(Doc.OuterXml)
    Response.End()
End Sub

The method GenerateData returns an XmlDocument object containing data retrieved using the query string parameter id.

My problem is that if the URL has a query string, the returned document is treated by the browser as ill-formatted HTML. If I omit the query string and pass a hard coded constant into GenerateData, the returned document is treated like an XML document and displays exactly as I would expect.

I have tried Request.QueryString.Clear and Request.QueryString.Remove("id"), and both generate a "Collection is read-only" error.

I would like to retain the flexibility of passing the search criteria through the query string and not have to deal with the Session object or form submissions. Any suggestions on how to get this to work?

ADDED

For what it is worth, this is the XML that gets generated whether I use the query string or an inline constant:

<?xml version="1.0" ?>
<EBulletinData>
  <Item>
    <EBulletinDate>6/9/2010 12:00:00 AM</EBulletinDate>
    <DepartmentId>5</DepartmentId>
    <Id>102</Id>
    <Introduction>
      <![CDATA[<p>Some text here.</p>]]>
    </Introduction>
    <Title>
      <![CDATA[Client Quarterly Available]]>
    </Title>
  </Item>
</EBulletinData>

With the constant, this is displayed by the browser (IE 8, at least) as a well-formatted XML file. With the query string, this same file is displayed as if it were badly-formatted HTML.

Solution

Boy, do I feel like a right idiot. I added the OutputCache Location="None" directive to the page, and suddenly the problem went away. Apparently, the query string version had been cached with some non-obvious errors, and it was this version that the server was returning. :doh:

Never mind, nothing to see here.