Don't call super.doGet: that's what is throwing the "GET not supported" error. The default implementation of doGet (i.e. the one defined in HttpServlet which is the super class here, is to print the message that GET is undefined. Because by default, you haven't defined it yet (i.e. not overloaded the doGet method). So when you call super.doGet its filling the response with the 405 headers. You don't want the super class to run its default method; you only want your overloaded method to run.
After you've called super.doGet the rest of your function is wrapped in a try with an empty catch. I think probably, if you were to output the error there to a log it would be something like "response headers already set" because the call to super.doGet already set the headers to content-type HTML, status 405, etc. so your attempt to change the content-type to PDF is going to throw an error there.
As to the rest of your problem, you have not set enough headers. Namely, you are missing these two:
I would advise just passing the servlet response outputstream directly into the getInstance method of the PDF writer:
(You probably also want to save the writer into a variable PdfWriter writer = PdfWriter.getInstance(....);) and maybe do something with it.
That way you aren't writing to a buffer, reading from the buffer, and finally writing to the response. It just writes the PDF to the response directly instead. And there's no need to manually flush or close the response buffer. Doing it this way does mean you can no longer set the content length header, but that one is not necessary anyway and will cause problems if you get it wrong.
Also, if you set the headers first, at the very top, then it will be locked in to serving the response as PDF even if it encounters an error and doesn't actually build a valid PDF, so that rather than ending up with a blank page, in the event of an error, you'll end up with a blank (i.e. corrupt) PDF. So at least the PDF application will open. It will just open with an error like "Could not open this PDF; it may be corrupt."
Great answer, however I have one comment: there is a reason why people write the PDF bytes to memory first. Some browsers can't deal with PDF very well. They read data in blocks of a fixed size, adding meaningless bytes at the end of the PDF file if its size isn't a multiple of the fixed size. The only way to work around this, is by adding a header with the file size response.setContentLength(pdfOutputStream.size());. The only way to know the file size, is to create the PDF in memory first.
Now that you mention it, I do recall that issue with IE6.