Accept-Encoding header missing

Hi,
we'd like to provide gzipped and packed200 jar of our application.Everything worked fine, we compressed our jar into .jar.gz and .pack.gz, achieved the usual checks.
They are all in the same directory.
But the problem is that our 1.5.0_04 jws never achieve a HTTP request with the Accept-Encoding header. So our application transfers the basic .jar file.
Is there a flag to set in our deployment file for the jws to ask the request with the header ?
Thanks in advance

Hi Andy,
I finally found that the problem was the symbolic jar URL into the JNLP descritption. It seems that the jar URL must end with ".jar"
I changed my servlet mapping from /myURL/jar to /myURL/some.jar and the 1.5 clients provided the accept-encoding header.
Thanks for your response by the way.

Similar Messages

Content-Transfer-Encoding Header missing?

Hello,
our Exchange 2013 CU 6 won't send "Content-Transfer-Encoding" Header when sending Mails to external Domains. (This Header is present if Mail stays within our Org)
Already tried to set different Encodings - but without luck ... Exchange just won't generate this Header ...
[PS] C:\Windows\system32>Set-RemoteDomain -Identity Default -ByteEncoderTypeFor7BitCharsets Use7Bit
[PS] C:\Windows\system32>Set-RemoteDomain -Identity Default -ByteEncoderTypeFor7BitCharsets UseBase64
[PS] C:\Windows\system32>Set-RemoteDomain -Identity Default -ByteEncoderTypeFor7BitCharsets UseQP
Hope someone here can help me with this!?
Thank you, bye from Austria
Andreas Schnederle-Wagner

Hi,
I suggest try to re-start the Transport service after running the commands you mentioned.
Please try to refer following KB to change the encoding type. I suggest make a backup before changing the value.
How to change the method for transfer encoding after you apply Exchange 2007 SP1 to the Exchange 2007-based server that is running the Hub Transport role
https://support.microsoft.com/kb/946641?wa=wsignin1.0
Thanks
If you have feedback for TechNet Subscriber Support, contact
[email protected]
Mavis Huang
TechNet Community Support

ACE 4710 one-arm L4 load balancing removes accept-encoding?

We have built a simple one-arm PAT config to round robin load balance two Varnish servers. In the "Default L7 load-balancing action" we have left compression to "N/A". It looks like the ACE removes "Accept-Encoding: gzip, deflate" from the client header.
Is this normal behaviour? We would like the Varnish to do the compression. Do we need modify the headers to get this through the ACE?

Hi,
Yes this does seem to be the behavior. Please read below:
HTTP compression is a capability built into web servers and web browsers to improve site performance by reducing the amount of time required to transfer data between the server and the client. Performing compression on the ACE offloads that work from the server, thereby freeing up the server to provide other services to clients and helping to maintain fast server response times.
When you enable HTTP compression on the ACE, the appliance overwrites the client request with "Accept-Encoding identity" and turns off compression on the server-side connection. HTTP compression reduces the bandwidth associated with a web content transfer from the ACE to the client.
So ACE rewrites the ACCEPT-ENCODING header to IDENTITY to indicate to the server that it should not compress the return data. That would be done by ACE.
Also, default method is used when client comes with both gzip or deflate for "ACCEPT ENCODING". For compression to work, a client must send a request with an ACCEPT-ENCODING method of gzip or deflate. If a client sends both methods, then the ACE uses the configured method(default method).
Also, you can see if ACE is compressing the packets or in "show service-policy detail.
switch/Admin#
show service-policy L7_COMP_SLB_POLICY detail
Status     : ACTIVE
Description: -----------------------------------------
Interface: vlan 1 108
service-policy: L7_COMP_SLB_POLICY
    class: vip
     VIP Address:    Protocol: Port:
     2.0.5.1         tcp        eq    80
      loadbalance:
        L7 loadbalance policy: pm
        VIP ICMP Reply       : ENABLED
        VIP state: OUTOFSERVICE
        Persistence Rebalance: ENABLED
        curr conns       : 0         , hit count        : 0
        dropped conns    : 0
        client pkt count : 0         , client byte count: 0
        server pkt count : 0         , server byte count: 0
        conn-rate-limit      : 0         , drop-count : 0
        bandwidth-rate-limit : 0         , drop-count : 0
        L7 Loadbalance policy : pm
          class/match : h
            ssl-proxy client : c
            LB action :
               primary serverfarm: sf1
                    state: DOWN
                backup serverfarm : -
            hit count        : 0
            dropped conns    : 0
            compression      : on <------------------------------ Compression is enabled if the value is "on"
compression bytes_in : 0       bytes_out : 0 <--- Number of bytes transmitted after compressing the server response
Compression ratio : 0.00% <------------------------------ Percentage of data compressed
Gzip: 0               Deflate: 0 <--------------- Number of times the method is used
compression errors:                                     _
User-Agent : 0               Accept-Encoding    : 0   |
Content size: 0               Content type       : 0   |
Not HTTP 1.1: 0               HTTP response error: 0   |-- Check these error counters to see if they are increasing
Let me know if you have any questions.
Regards,
Kanwal

MIME header missing "filename=" results in BAD messages

I've been trying to track down several issues involving what appear to
be MIME handling issues. We are running GroupWise v7.01 (we have not
installed the "interim release" yet), and all components on the server
are at that release level (MTA, POA, GWIA, WebAccess).
One of the issues I am currently working on involves problems receiving
attachments from an outside sender. Their attachments are readable if
sent to an outside test account (i.e. - we've tested it with Yahoo
web-based mail, and a RoadRunner POP3 account using Outlook as the client).
The problem is that these e-mails either get dumped by the GWIA to the
GWPROB directory, or the e-mails go through, but the attachments are
corrupted (they do show up as attachments to the e-mail, but are
unreadable).
I haven't looked at why some e-mails go through and some don't, but I
did find out why the attachments are unreadable on the delivered
e-mails, and why the rest are just undeliverable. For whatever reason,
the sender's mail server (or AV gateway or whatever else had a chance to
touch the e-mail) is either not inserting, or is stripping out the
"filename=" from the MIME header just before the encoded attachment.
Adding this back into the message (by editing the original e-mail
w/header, and dropping the modified message into the GWIA "RECEIVE"
directory) fixes the attachment AND makes the e-mail deliverable.
Below I have an example of a bad e-mail which was originally sent to our
GWPROB directory, but was successfully delivered with a readable
attachment through a separate POP3 account (RoadRunner). Following this
"bad" e-mail example is the "fixed" version of that same e-mail, which
was delivered successfully to our user, with the attachment also being
readable.
*************** This is the original "BAD" e-mail ***************
MAIL From:<[email protected]> SIZE=73686
RCPT To:<[email protected]>
Received: from test.rr.com ([65.xx.xx.xx])
by smtp.ourhost.com with ESMTP; Wed, 21 Feb 2007 15:28:27 -0500
Received: from local.com (rrcs-24-xx-xx-xx.central.biz.rr.com [24.xx.xx.xx])
by test.rr.com (8.13.6/8.13.6) with ESMTP id l1LKSFTm009106
for <[email protected]>; Wed, 21 Feb 2007 15:28:24 -0500 (EST)
Message-Id: <[email protected]>
From: [email protected]
To: [email protected]
Date: Wed, 21 Feb 2007 15:25:54 -0500
MIME-Version: 1.0
X-Mailer: Telexis Gateway
Content-Type: multipart/mixed;
boundary="Mark=Num1_Lev1_2007221202554265_Tlx"
X-Virus-Scanned: Symantec AntiVirus Scan Engine
--Mark=Num1_Lev1_2007221202554265_Tlx
Content-Type: text/plain
Content-Transfer-Encoding: Quoted-Printable
This is a test
-Test Sender
--Mark=Num1_Lev1_2007221202554265_Tlx
Content-Type: application/vnd.ms-excel;
name="1st Q 2007 Income to Budget.xls"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
"1st Q 2007 Income to Budget.xls"
0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAAZgAAAAAAAAAA
EAAA/v///wAAAAD+////AAAAAGUAAAD/////////////////////////////////////////////
--Mark=Num1_Lev1_2007221202554265_Tlx--
************** END OF BAD E-MAIL **************
*************** This is the "fixed" e-mail ***************
MAIL From:<[email protected]> SIZE=73686
RCPT To:<[email protected]>
Received: from test.rr.com ([65.xx.xx.xx])
by smtp.ourhost.com with ESMTP; Wed, 21 Feb 2007 15:28:27 -0500
Received: from local.com (rrcs-24-xx-xx-xx.central.biz.rr.com [24.xx.xx.xx])
by test.rr.com (8.13.6/8.13.6) with ESMTP id l1LKSFTm009106
for <[email protected]>; Wed, 21 Feb 2007 15:28:24 -0500 (EST)
Message-Id: <[email protected]>
From: [email protected]
To: [email protected]
Date: Wed, 21 Feb 2007 15:25:54 -0500
MIME-Version: 1.0
X-Mailer: Telexis Gateway
Content-Type: multipart/mixed;
boundary="Mark=Num1_Lev1_2007221202554265_Tlx"
X-Virus-Scanned: Symantec AntiVirus Scan Engine
--Mark=Num1_Lev1_2007221202554265_Tlx
Content-Type: text/plain
Content-Transfer-Encoding: Quoted-Printable
This is a test
-Test Sender
--Mark=Num1_Lev1_2007221202554265_Tlx
Content-Type: application/vnd.ms-excel;
name="1st Q 2007 Income to Budget.xls"
Content-Transfer-Encoding: base64
Content-Disposition: attachment;
filename="1st Q 2007 Income to Budget.xls"
0M8R4KGxGuEAAAAAAAAAAAAAAAAAAAAAPgADAP7/CQAGAAAAAAAAAAAAAAABAAAAZgAAAAAAAAAA
EAAA/v///wAAAAD+////AAAAAGUAAAD/////////////////////////////////////////////
--Mark=Num1_Lev1_2007221202554265_Tlx--
************** END OF "FIXED" E-MAIL **************
The only change I made, which both allowed the above e-mail to be
delivered and made the attachment readable, was the addition of the
"filename=" just before the file name on the line after the
"Content-Disposition: attachment;".
I did the same test with an e-mail that had the same "filename="
missing, but somehow was successfully delivered to our user (again, the
attachment was unreadable). Adding the "filename=" into the resent
message did make the attachment readable.
I haven't looked to see if the sender's system is actually non-compliant
for excluding the "filename=" (I will be doing that later this evening),
or whether this is a GWIA problem for not being able to handle this. I
just wanted to throw this out there to see if anyone else has seen this.
Does the "interim release" update by chance fix this?
Thanks,
Greg Niese

Does this email come in directly to GWIA (or do you have a relay host in
between)? I must say I've never experienced this problem on any of the GW
systems I administer. Could you tell us what domain this is coming from?
Ted Kumsher
>>> On 2/23/2007 at 8:21 AM, in message
<[email protected]>, Greg
Niese<[email protected]> wrote:
> I agree that this shouldn't be accepted as a valid "filename parameter"
> line. There are two ways to "not accept" this invalid parameter: "stop
> processing" the e-mail because of the problem (discard the e-mail), or
> discard the bad parameter and continue processing the rest of the e-mail
> (this could only work when the parameter is optional, as in this case).
> The GWIA seems to take the route of "stop processing", and then moving
>
> the resultant "bad" e-mail to the GWPROB directory.
>
> I say "seems" because in many cases where this occurs the e-mail doesn't
> get sent to the GWPROB directory, but instead still gets through the
> GWIA to the user. The attachments are corrupted, but still show up
> correctly in the attachment window, so everything seems OK with the
> e-mail & attachment - until you try to open the attachment.
>
> If there is a semi-colon after the "Content-disposition" type, the GWIA
> should see a valid disposition parameter following. But if it sees an
> invalid parameter, as in this case, what is the GWIA doing? It must
> either be discarding the invalid parameter, or "uses" it by either
> incorrectly parsing it as part of the header, or lumping it in as part
> of the attachment. If it "uses" in any way the invalid line of data -
> that sounds like the definition of "accepting" it, isn't it?
>
> To test whether the GWIA is actually using, and therefore "accepting",
> this bad parameter, I simply removed the malformed parameter (having the
>
> line in or out shouldn't matter if the GWIA's not using it), and I tried
>
> this both with the semi-colon removed from the end of the
> "content-disposition" type, and with that semi-colon left in place. In
> both cases the GWIA properly processed the e-mail and the attachment was
> readable! What does that mean? If the GWIA was truely NOT
> using/accepting that invalid header parameter (i.e. - the GWIA discards
> it), then the e-mail and attachment should go through OK. Since this
> isn't what happens when the bad line is left in place (the attachments
> DO NOT come through OK, but the e-mail often does get to the user's
> mailbox), then the GWIA must be accepting that bad parameter as either a
>
> part of the header, or a part of the attachment.
>
> I suspect that in those cases that these e-mails are sent to the problem
> directory, instead of being delivered with a corrupt attachment, the
> GWIA isn't really recognizing that the optional disposition parameter is
>
> "bad". The reason for the e-mail going to the problem directory is
> probably due to an error while trying to decode the attachment if the
> bad parameter is treated as part of the attachment, or if part of the
> attachment is being lumped in with the malformed parameter as it is
> parsed.
>
> I agree that how the GWIA should go about "not accepting" bad header
> parameters may be debatable (assuming that the GWIA were actually
> halting processing of the e-mail when this type of problem is found, and
> then sending the e-mail to the problem directory every time). But in
> cases such as this, since the parameter itself is optional, it would
> seem that the better route would be for the GWIA to discard the
> parameter and continue processing, instead of "discarding" the whole
> e-mail (to the problem directory). "Discarding the bad parameter" seems
> to be what is being done by at least a few other competing SMTP agents,
> since the other mail systems I tested with did get the e-mail through
> without corrupting the attachment.
>
> I may suggest that the sender's company fix whatever is going on at
> their server, but it probably won't do any good (I've already been told
> that they don't experience this problem with anyone else). In the
> meantime, my user (yes...he is the CEO), will have to continue to have
> some important e-mails sent to one of his personal accounts, because
> those e-mail systems receive these e-mails fine, but our GroupWise
> system can't.
>
> :-(
>
> -Greg
>
>
>
> Michael Bell wrote:
>> No it shouldn't, IMO.
>>
>> It's a matter of interpretation, of course. But GWIA is 100% right in
> not
>> accepting this as vaid (that part is beyond any debate - it's in the
> RFC).
>>
>> The only part that can be debated is "should GWIA then pass the buck"?.
> In
>> olden days, many would have said yes.
>>
>> But In general, no. Moving away from Postel's law, which was formulated
> in a
>> pre-malware age, is pretty much needed. Tight specifications and
> pickiness
>> is good. Collateral damage is unfortunate, and of course one needs to be
>
>> flexible if this is a widespread issue (which frankly, it is not in this
>
>> case), but otherwise it is up to to sender to fix their issue.
>>
>> 90% of viruses and malware in the last 6 years (and I'm well aware of
> them,
>> working in the email security field) are from MALFORMED e-mail, that the
>> gateway and client misinterpreted. Many of these were MS issues, but
> that's
>> another point. Point is you have to be STRICT.
>>
>> In this case this violates the generic MIME RFCs which state that if you
> do
>> have parameters, they all gotta be separated with semicolons (PASS), and
>
>> have to be name=value pairs (FAIL).
>>
>>
>> "Greg Niese" <[email protected]> wrote in message
>> news:[email protected]...
>>> Well, according to RFC 2183, the "filename=" string has to be present if
>
>>> the Filename parameter is going to be used. So the sending host seems
> to
>>> be "broken" in that regard.
>>>
>>> My next question then is: Should the GWIA ignore the "stray" file name
> in
>>> these e-mail headers, instead of allowing it to be lumped in with the
>>> attachment (I'm assuming that's why the attachment is trashed)? It
>>> appears that other systems are able to do this.
>>>
>>> -Greg
>>>
>>> Greg Niese wrote:
>>>> I haven't looked to see if the sender's system is actually
non-compliant
>>>> for excluding the "filename=" (I will be doing that later this
evening),
>
>>>> or whether this is a GWIA problem for not being able to handle this. I
>>>> just wanted to throw this out there to see if anyone else has seen
this.
>>>>
>>>> Does the "interim release" update by chance fix this?
>>>>
>>>> Thanks,
>>>>
>>>> Greg Niese
>>>>
>>
>>

Cache-Control and Accept-Encoding support in Adobe AIR HTML Component

I am evaluating Adobe AIR's HTML component and trying to figure out what is supported.
I built the AIR app and had it point to www.google.com
I notice that the requests to fetch JS,CSS from Adobe AIR do not include Accept-Encoding: gzip header.
Does Adobe AIR's HTML Component support Accept-Encoding : gzip header ?
I also noticed that even though the content served with far futures expiry, i.e. has Cache-Control: maxage={value} subsequent requests are being made and content is not served from the browser's cache.
I observed this accross the app restarts.
Can someone please clarify support of the two above Http headers ?
Thank you.
-Prashant

You might also want to check out the useCache property to see if this helps. See these links:
http://forums.adobe.com/thread/726573
http://forums.adobe.com/thread/490497
http://help.adobe.com/en_US/FlashPlatform/reference/actionscript/3/flash/html/HTMLLoader.h tml

Header missing in SOAP message header (SAP XI Extension)

Hi Experts,
We are implementing interface MasterDataUpdateConfirmation_Out between 2 SAP ERP systems. The middleware is SAP PI.
SAP PI team requested a change in this interface Stack - Replace Stack ABAP by Stack Java. The changes were made.
However, now we get an error in the interface in the SAP ERP sender system, but the message arrives to SAP PI where is processed without errors and also arrives to SAP ERP receive system and the message is also processes without errors.
The error we have in XML message in SAP ERP sender system is:
XML element {http://schemas.xmlsoap.org/soap/envelope/}Header missing in
SOAP message header (SAP XI Extension)
Exception of class CX_XMS_SYSERR_PARSER
Can anyone please help us? We have no ideia what to do.
Thanks in advance,
RS

Hi again,
I don't know if it is important, but the communication is asynchronous and the sender system is SAP ECC 6.0.
Thanks!

Any way to change the Accept-Encoding in apache/jsp?

I have a jsp page which needs to not be delivered using gzip compression and currently my apache is configured to compress any text content. IS there anyway to diable the gzip encoding through a request, or response command OR an directive at the top of the jsp page?
the browser sends "Accept-Encoding: gzip" by default which causes the apache to compress the content that is returned.
Any help would be appreciated...thanks!

ok got it ...The solution doesnt involve any java/jsp but basically i excluded those pages from being gzipped in the <ifmodule> statement in the httpd.conf for apache:
SetEnvIfNoCase Request_URI \
(test1|test2)\.(?:jsp)$ no-gzip dont-vary
It took me a while to get here since I thought initially it was a problem wiht out.flush() not working properly.
The reason why I want to do it is because I have a backend process that takes sometime to return completely and in the meantime i want to show the part of the page that has partially loaded. Its more involved than the example page that I showed you and is somewhat resistant to reworking but it is the same principal .
Thanks for all your help!

Flash 11 sending incorrect accept-language header in IE9

I am building a website and while web requests from the browser and from javascript report the correct accept-language header (as set inside the IE9 properties, as well as set in system settings on Windows), Flash continues to send English. This seems to be a bug in Flash as I can see no other way to force it to send the same value as the browser.
Can someone confirm this? Also, our Flash developer says that when he looks inside the capabilities object for the current language, it seems that he's also getting the incorrect one. From my research, it sounds like IE sends scripts and plugins only the System Localization language (ie Language in which Windows was shipped), and not the system setting language.
However, since Flash seems to be using the browser http stack for its web calls, I don't see why this behavior should be broken on IE when it works fine for Firefox, Chrome and Opera.

I don't think this is new behavior. When searching on Google, I found a similar post from years ago about this same issue. To reproduce it, get on any internet explorer, set your language to something other than English (or whatever your default happens to be currently).
Go to a website like speedtest.com and press f12 for the developer tools. go to the network tab and enable network monitoring. refresh the page. you will see that all of the page requests send accept-language correctly as your new language.
Next, run the speedtest. you will see a bunch more requests pop up in the network monitor. check the headers. it will send accept-language as en-US, regardless of your settings.
https://bugbase.adobe.com/index.cfm?event=bug&id=3154517

Accept-encoding "compress"

Hello,
I'm compressing xml responses using "gzip" and "deflate" for requests with Accept-encoding "gzip" or "deflate" (or both).
The problem is that I have a client that only uses "compress" (and this is not "negotiable", he'll only send "accept-encoding=compress").
Is this compression format supported in jdk 5? For gzip I use GZIPInput/Outstream, and for deflate I use Inflater/Deflater. But for compress? Maybe is a variant of Inflater/Deflater? Can anybody help me, please?
Thanks,
Joan.

No, there's no support for compress in the public Java SE 5.0 API. The compress algorithm (LZW) was largely obsoleted 15-or-so years ago by algorithms like deflate that decode faster and compress better.

Messages App - 'Accept' button is missing with incoming audio chats

Hello,
10.9.1 didn't solve a problem I have since 10.9.
If somebody calls me within Messages App for an audio chat, the 'Accept' Button is missing.
(see screenshot)
Can anybody help?
Kind regards
Carl

Hi,
Yes. Messages is iChat under the hood.
Lion had iChat 6. Mountain Lion gets Messages 7.x.x and Mavericks Messages 8
There are separate .plist that have iMessages in the name for the account stuff like there are iChat ones for the AIM, Jabber and Yahoo accounts.
(it is similar to the Contacts app still using a .plist for the Address Book).
If your settings are not that different from the defaults then you will not notice anything.
For instance I use Arial Black and a green background (custom choice) in Preferences > Viewing. (the default is Helvetica)
Also in the General section I have the item about gathering all buddy lists unticked so that they are separate.
I also use the Show Status item to display the Menu Bar icon.
In Messages the Chats are all in the main window listed down the left with the highlighted on shown in the right hand pane.
You can double click any of the listed ones and a separate chat will open (the main window can then be closed/hidden) but there is no way to start a new chat in it's own window.
If you create a new Mac User account (System Preferences > Users and Groups) and then login in to that account and use Messages there does it have the the missing buttons ?
This will help prove it is the app (A Restore will be needed) or something about the saved state of the app in your regular User account.
8:51 pm Thursday; December 19, 2013
 iMac 2.5Ghz 5i 2011 (Mavericks 10.9)
 G4/1GhzDual MDD (Leopard 10.5.8)
 MacBookPro 2Gb (Snow Leopard 10.6.8)
 Mac OS X (10.6.8),
 Couple of iPhones and an iPad

ODI Web Service Soap Header Missing Error

I am trying to invoke oracle crm ondemand web service using ODIInvokeWebService tool by providing the below parameters
Url
Port Type
Operation
XML Request
HTTP User
HTTP Password
I am getting the below error during the execution of the step.
javax.xml.ws.soap.SOAPFaultException: Invalid Soap Request : Soap Header is missing
     at com.sun.xml.ws.fault.SOAP11Fault.getProtocolException(SOAP11Fault.java:189)
     at com.sun.xml.ws.fault.SOAPFaultBuilder.createException(SOAPFaultBuilder.java:122)
     at com.sun.xml.ws.client.dispatch.DispatchImpl.doInvoke(DispatchImpl.java:187)
The code which is getting executed is
OdiInvokeWebService "-URL=http://slc402454.us.oracle.com:30090/Services/cte/FieldManagementService?wsdl" "-PORT_TYPE=FieldManagementService" "-OPERATION=FieldManagementRead" "-HTTP_USER=Upgrade_all/sales" "-HTTP_PASS=aYyHL7THHZYEdPNTd.1ugy"
<?xml version = '1.0' encoding = 'UTF8'?>
<WL5G3N1:FieldManagementRead_Input xmlns:env="http://schemas.xmlsoap.org/soap/envelope/" xmlns:WL5G3N1="urn:crmondemand/ws/odesabs/fieldmanagement/">
<apQuery:FieldSet xmlns:apQuery="urn:/crmondemand/xml/fieldmanagement/query">
<apQuery:ObjectName>Account</apQuery:ObjectName>
<apQuery:IncludeAll>true</apQuery:IncludeAll>
</apQuery:FieldSet>
</WL5G3N1:FieldManagementRead_Input>
With SOAPUI , I am able to get the response.

After mentioning the SOAP header and response file as XML with other properties , I am able to successfully retrieve the SOAP response.

Copyright Header missing in mxml?

Hi,
How does one correct the violation "Copyright header info is missing" in an mxml file? We do have a copyright header in all our mxml files, but they are not being picked up by FlexPMD. Does it look for a specific copyright header?
Thanks

Hi,
If you still having the same issue, try removing the space in between
Not Good:
<?xml version="1.0" encoding="utf-8"?>

Good
<?xml version="1.0" encoding="utf-8"?>

Choose value of Accept-Language: header

Hello,
I have a problem: I use Safari on an english language system, but I would like it to request pages in French, sending the following header: "Accept-Language: fr"
Couldn't find this in the preferences, as in Firefox, did I miss something? And there's no way I'll change my system's language just for that
thanks

No way to do what you want in Safari yet.
To tell Apple you want it, use the Report bugs item in the Safari menu.

Errow message print head missing or not reconise

i am getting an errow message that theone print head is missing. i have seen orther folk on hp chat site having the same problem with their hp 6700 premium. i have had my printer only a year and a half.

Hi jblowery,
I would like to help you with the printhead issue you are experiencing. It looks like there are minimal troubleshooting steps that can be done, please take a look at the following document to see; A 'Missing or Failed Printhead' Error Message Displays on the Printer or on the Computer.
Please click the Thumbs up icon below to thank me for responding.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Please click “Accept as Solution” if you feel my post solved your issue, it will help others find the solution.
Sunshyn2005 - I work on behalf of HP

Apache Tomcat Transfer-Encoding Header Vulnerability

My most recent Nessus report gave the following risk warning. Apparently I need to upgrade my BO XI deployment to Tomcat 5.5.30 from 5.5.20. Has anyone else undertaken this effort? Can someone tell me what's involved? Thanks!
Synopsis:
The remote Apache tomcat service is vulnerable to an information disclosure or a denial of service attack.
Description:
The remote Apache Tomcat service is vulnerable to information disclosure or a denial of service attack due to a mishandling of invalid values for the 'Transfer-Encoding' HTTP header as sent by a client.
Risk factor:
Medium
CVSS Base Score:6.4
CVSS2#AV:N/AC:L/Au:N/C:P/I:N/A:P
See also:
http://tomcat.apache.org/security-5.html#Fixed_in_Apache_Tomcat_5.5.30
See also:
http://tomcat.apache.org/security-6.html#Fixed_in_Apache_Tomcat_6.0.28
Solution:
Upgrade to version 5.5.30 / 6.0.28 or greater.
Plugin output:
Nessus was able to verify this issue using the following request : GET / HTTP/1.1 Host: omiprm043 Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, image/png, / Date: Wed, 25 Aug 2010 21:34:52 GMT User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1; Trident/4.0) Accept-Charset: iso-8859-1,utf-8;q=0.9,*;q=0.1 Pragma: no-cache Transfer-Encoding: NESSUS Accept-Language: en Connection: Close
Plugin ID:
47749
CVE:
CVE-2010-2227
BID:
41544
Other references:
OSVDB:66319, Secunia:39574

Hi,
According to my experiences if you update tomcat where you can , BO XI platform might have problems. My suggestion is for you is to full backup system before anything you do, Also you can update BO XI where you can have a new version of tomcat embeeded.
Regards.

Accept-Encoding header missing

Similar Messages

Maybe you are looking for